DJ VinylTouch
The wiki describing transferring settings to a new computer states that the settings.xml shouldn't be transferred, but regenerated, and settings manually entered on the new machine.
While I can understand why that would be recommended (file path differences, missing plugins, architecture differences, etc), I think most of us spend a lot of time tuning those settings to be right, and it is a bit time consuming/error prone to replicate that over. Is it possible for the backup process to take care of this, skipping the settings that most likely won't be applicable/setup on the new machine?
While I can understand why that would be recommended (file path differences, missing plugins, architecture differences, etc), I think most of us spend a lot of time tuning those settings to be right, and it is a bit time consuming/error prone to replicate that over. Is it possible for the backup process to take care of this, skipping the settings that most likely won't be applicable/setup on the new machine?
Inviato Wed 02 Aug 23 @ 3:29 pm
kradcliffe
I've always just copied over the settings.xml from one machine to another and not had any issues. And I'm still on the orignal database from 2008 despite several changes of machine.
Inviato Wed 02 Aug 23 @ 3:48 pm
DJ VinylTouch
So given the machines are close to each other in specs and you've set stuff up pathwise/otherwise to be identical it should work, but I get the feeling this could break in funny ways, and that's why they don't recommend it. It would be nice if VirtualDJ just took care of this though, the settings is one of the most painstaking processes of getting it to work exactly as we want it - I swear it's one of the places I've spent the most time in the beginning, and I've forgotten half of the things I've setup.
Inviato Wed 02 Aug 23 @ 3:59 pm
kradcliffe
I've even carried a Windows settings file over to a mac and everything just worked. Of course it's always worth a look at modified fields to see if anything stands out but as I said above I've never had any issues doing this in 15 years.
Inviato Wed 02 Aug 23 @ 4:07 pm
PhantomDeejay
Yes, it is recommended to regenerate the settings file in order to "play safe"
However personally I use Dropbox to synchronize my entire VirtualDJ system (including music and database) among 3 different PCs without any issues whatsoever.
The only thing I need to keep in mind, is to set stems settings accordingly in each machine when I need to use stems 2.0
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
Other than that, VirtualDJ settings are pretty much universal among systems.
However, it is still recommended to rebuild the settings (or at least review them if you are a power user) for each new PC/MAC
However personally I use Dropbox to synchronize my entire VirtualDJ system (including music and database) among 3 different PCs without any issues whatsoever.
The only thing I need to keep in mind, is to set stems settings accordingly in each machine when I need to use stems 2.0
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
Other than that, VirtualDJ settings are pretty much universal among systems.
However, it is still recommended to rebuild the settings (or at least review them if you are a power user) for each new PC/MAC
Inviato Wed 02 Aug 23 @ 10:23 pm
DJ VinylTouch
PhantomDeejay wrote :
Yes, it is recommended to regenerate the settings file in order to "play safe"
However personally I use Dropbox to synchronize my entire VirtualDJ system (including music and database) among 3 different PCs without any issues whatsoever.
The only thing I need to keep in mind, is to set stems settings accordingly in each machine when I need to use stems 2.0
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
Other than that, VirtualDJ settings are pretty much universal among systems.
However, it is still recommended to rebuild the settings (or at least review them if you are a power user) for each new PC/MAC
However personally I use Dropbox to synchronize my entire VirtualDJ system (including music and database) among 3 different PCs without any issues whatsoever.
The only thing I need to keep in mind, is to set stems settings accordingly in each machine when I need to use stems 2.0
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
Other than that, VirtualDJ settings are pretty much universal among systems.
However, it is still recommended to rebuild the settings (or at least review them if you are a power user) for each new PC/MAC
While I know it's possible (I had the same issue with my older intel MacBook Air vs my M1), wouldn't it be easier to have those settings reproducible as as part of the backup/restore process? VirtualDJ itself would know what is a "safe" setting from what isn't based on various environments and could even adjust to suit.
Inviato Wed 02 Aug 23 @ 11:08 pm
PhantomDeejay
AFAIK they are part of the backup/restore process.
Inviato Thu 03 Aug 23 @ 12:22 am
kradcliffe
I think what he's asking for is some kind of automatic check when VDJ is started up to see if any of the modified settings carried over are incorrect.
Inviato Thu 03 Aug 23 @ 6:42 am
Niels (cph)
PhantomDeejay wrote :
The only thing I need to keep in mind, is to set stems settings accordingly in each machine when I need to use stems 2.0
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
I also keep 2 machines synchronized (using iCloud Drive, but same same), and have the same little inconvenience with a few settings I want set differently on the 2 machines.
Seeing that you have the same setup, got me thinking. How about implementing a mechanism with machine specific settings.xml. I.e., use some unique ID of the machine (MAC address or similar) in the file name.
For instance, say that your VirtualDJ folder is synced to 3 machines, after having launched VDJ once on each machine, the folder will then contain 3 settings xml files like this: settings_0a-fc-99-1a-2b-3c.xml.
That would be a nice feature.. 😊
Inviato Thu 03 Aug 23 @ 8:38 am
kradcliffe
I have asked for something similar previously as I have different lighting setups and would like to have different custom button DMX assignments for different gigs. Would be great to have some inbuilt way of swapping settings files on the fly as all the custom buttoms are stored there.
Inviato Thu 03 Aug 23 @ 8:40 am
Niels (cph)
PhantomDeejay wrote :
The only thing I need to keep in mind, is to set stems settings accordingly in each machine when I need to use stems 2.0
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
That's because only my main laptop is truly capable of doing real time stems 2.0 separation.
I also keep 2 machines synchronized (using iCloud Drive, but same same), and have the same little inconvenience with a few settings I want set differently on the 2 machines.
Seeing that you have the same setup, got me thinking. How about implementing a mechanism with machine specific settings.xml. I.e., use some unique ID of the machine (MAC address or similar) in the file name.
For instance, say that your VirtualDJ folder is synced to 3 machines, after having launched VDJ once on each machine, the folder will then contain 3 settings xml files like this: settings_0a-fc-99-1a-2b-3c.xml.
That would be a nice feature.. 😊
Inviato Thu 03 Aug 23 @ 8:55 am
PhantomDeejay
kradcliffe wrote :
I have asked for something similar previously as I have different lighting setups and would like to have different custom button DMX assignments for different gigs. Would be great to have some inbuilt way of swapping settings files on the fly as all the custom buttoms are stored there.
Instead of custom buttons, you could use custom pad pages instead. This way you could have a different pad page per setup.
Or, you could use variables to have the same button operate different functions depending on the setup/variable. var_equal '@$DMXProfile' 0 ? dmx_action 1 : var_equal '@$DMXProfile' 1 ? dmx_action 2 : var_equal '@$DMXProfile' 2 ? dmx_action 3
You could even change the name of the buttons with the same way. Just remember to include the ticks in the name box `var_equal '@$DMXProfile' 0 ? get_text 'STROBE' : var_equal '@$DMXProfile' 1 ? get_text 'FREEZE' : var_equal '@$DMXProfile' 2 ? get_text 'WASH RED'`
PS: I'm not against your request. That's why requests exist in the first place. I just wanted to provide you with a solution until your request becomes true.
Inviato Thu 03 Aug 23 @ 11:21 am
kradcliffe
Thanks George. I just bought some new heads and will have to redo the buttons so I will look at that.
The other option would for VDJ to have some sort of custom button manager. I had a previous post on this and I understand how they work but woukd be easier with a user interface
The other option would for VDJ to have some sort of custom button manager. I had a previous post on this and I understand how they work but woukd be easier with a user interface
Inviato Thu 03 Aug 23 @ 11:28 am
DJ VinylTouch
kradcliffe wrote :
I think what he's asking for is some kind of automatic check when VDJ is started up to see if any of the modified settings carried over are incorrect.
This.
Inviato Thu 03 Aug 23 @ 1:56 pm
PhantomDeejay
How would this work though ?
How do you define "incorrect" vs deliberately set ?
I mean let's take realTimeStemsSeparation as an example.
How do you tell if "fully Disabled" is "wrong" on a machine ?
My machine may be 100% capable of stems 2.0, but I may deliberately have set them to fully disabled because I never use them.
Or I may have set them to "Prepared Only" because I also do video occasionally and I'm afraid that they may interfere with video output (if my fear is justified or not doesn't really matter).
So, if the program sees an RTX 3080 should it change "Prepared Only" to "Always" by it's own ?
How would the program determine if a setting is "wrong" or not ?
PS: For the most part for hardware related things like which GPU to use for skin / video drawing e.t.c. the program already automatically takes care of this.
How do you define "incorrect" vs deliberately set ?
I mean let's take realTimeStemsSeparation as an example.
How do you tell if "fully Disabled" is "wrong" on a machine ?
My machine may be 100% capable of stems 2.0, but I may deliberately have set them to fully disabled because I never use them.
Or I may have set them to "Prepared Only" because I also do video occasionally and I'm afraid that they may interfere with video output (if my fear is justified or not doesn't really matter).
So, if the program sees an RTX 3080 should it change "Prepared Only" to "Always" by it's own ?
How would the program determine if a setting is "wrong" or not ?
PS: For the most part for hardware related things like which GPU to use for skin / video drawing e.t.c. the program already automatically takes care of this.
Inviato Fri 04 Aug 23 @ 9:41 am
locoDog
@Niels make your shortcut to launch vdj a .bat or .ps1 ?
Inviato Fri 04 Aug 23 @ 9:59 am
DJ VinylTouch
PhantomDeejay wrote :
How would this work though ?
How do you define "incorrect" vs deliberately set ?
I mean let's take realTimeStemsSeparation as an example.
How do you tell if "fully Disabled" is "wrong" on a machine ?
My machine may be 100% capable of stems 2.0, but I may deliberately have set them to fully disabled because I never use them.
Or I may have set them to "Prepared Only" because I also do video occasionally and I'm afraid that they may interfere with video output (if my fear is justified or not doesn't really matter).
So, if the program sees an RTX 3080 should it change "Prepared Only" to "Always" by it's own ?
How would the program determine if a setting is "wrong" or not ?
PS: For the most part for hardware related things like which GPU to use for skin / video drawing e.t.c. the program already automatically takes care of this.
How do you define "incorrect" vs deliberately set ?
I mean let's take realTimeStemsSeparation as an example.
How do you tell if "fully Disabled" is "wrong" on a machine ?
My machine may be 100% capable of stems 2.0, but I may deliberately have set them to fully disabled because I never use them.
Or I may have set them to "Prepared Only" because I also do video occasionally and I'm afraid that they may interfere with video output (if my fear is justified or not doesn't really matter).
So, if the program sees an RTX 3080 should it change "Prepared Only" to "Always" by it's own ?
How would the program determine if a setting is "wrong" or not ?
PS: For the most part for hardware related things like which GPU to use for skin / video drawing e.t.c. the program already automatically takes care of this.
So with your example = realTimeStemsSeparation
Anything lower than "always", coming in from the settings file, can't be "wrong"... it would be interpreted as a personal choice that machines that meet minimum recommended specifications should be able to handle, and you can leave that setting as is.
If you encounter "always" however, that can only be handled by machines that meet the minimum stems 2.0 specs. If the machine does not meet that requirement, the setting can be bumped down to the lowest that can work without issue/extra usage of disk space (e.g. reduced or fully disabled), and a modal window can display a brief comment of detection of the problematic setting and resulting choice on first startup (it probably could list all such problematic settings and maybe even back up the original settings file before modifying the choices, reporting the backup file location also).
There is also the case of your new machine being better in specs, so that it can handle the "always" setting. In that case, you still don't bump it up, you leave it as is, but report that it can be bumped up (maybe a separate handling window of improvable performance settings can be introduced for this?).
Similar can probably done for references to non-existent paths (clear or default them), non-existent/non-applicable plugins, audio settings, etc (clear them). I'm probably oversimplifying and missing some points, but from a high level it seems doable, just as long as the resulting changes don't break startup/usability and users get a report of the changes.
Inviato Fri 04 Aug 23 @ 11:51 am
PhantomDeejay
I'm not sold.
Because this way of thinking makes things far more complicated for the vast majority of users (that don't really copy/move settings.xml between multiple systems) in order to potentially "ease" just a few.
The software should not produce "unexpected" behavior.
For any software, if I (as a user) set a setting, I want it to stay there. That's why settings exist. Having the software "check" the user settings and readjust them on every launch defeats that purpose of having a setting IMHO.
Maybe an action (that you would launch manually by yourself) that would "check" and validate settings could be a better option.
Finally imagine the hassle of getting a "report" every time you start VirtualDJ. Most users would not even read what it says and they would just click ok.
Or imagine that you have set to have your prepared stems saved on an external HDD and you start the program (by mistake or just for a quick irrelevant task) without the external connected.
Boom! Out the door goes your saved path for prepared stems. And next time you have to configure it again. That's if you are not caught off guard in the middle of a gig wondering why your saved stems don't load / work.
PS: This is not a debate. It's a discussion to see if there's any protentional way to implement this without causing issues to the rest users (as I mentioned in my first sentence)
Because this way of thinking makes things far more complicated for the vast majority of users (that don't really copy/move settings.xml between multiple systems) in order to potentially "ease" just a few.
The software should not produce "unexpected" behavior.
For any software, if I (as a user) set a setting, I want it to stay there. That's why settings exist. Having the software "check" the user settings and readjust them on every launch defeats that purpose of having a setting IMHO.
Maybe an action (that you would launch manually by yourself) that would "check" and validate settings could be a better option.
Finally imagine the hassle of getting a "report" every time you start VirtualDJ. Most users would not even read what it says and they would just click ok.
Or imagine that you have set to have your prepared stems saved on an external HDD and you start the program (by mistake or just for a quick irrelevant task) without the external connected.
Boom! Out the door goes your saved path for prepared stems. And next time you have to configure it again. That's if you are not caught off guard in the middle of a gig wondering why your saved stems don't load / work.
PS: This is not a debate. It's a discussion to see if there's any protentional way to implement this without causing issues to the rest users (as I mentioned in my first sentence)
Inviato Fri 04 Aug 23 @ 12:14 pm
Niels (cph)
locodog wrote :
@Niels make your shortcut to launch vdj a .bat or .ps1 ?
Sure, absolutely the way to work around it. But seeing that one of the core devs is in the same situation, I thought I would pitch the idea for a simple builtin per-machine-settings mechanism.. 😊
Inviato Fri 04 Aug 23 @ 1:01 pm
DJ VinylTouch
PhantomDeejay wrote :
I'm not sold.
Because this way of thinking makes things far more complicated for the vast majority of users (that don't really copy/move settings.xml between multiple systems) in order to potentially "ease" just a few.
The software should not produce "unexpected" behavior.
For any software, if I (as a user) set a setting, I want it to stay there. That's why settings exist. Having the software "check" the user settings and readjust them on every launch defeats that purpose of having a setting IMHO.
Maybe an action (that you would launch manually by yourself) that would "check" and validate settings could be a better option.
Finally imagine the hassle of getting a "report" every time you start VirtualDJ. Most users would not even read what it says and they would just click ok.
Or imagine that you have set to have your prepared stems saved on an external HDD and you start the program (by mistake or just for a quick irrelevant task) without the external connected.
Boom! Out the door goes your saved path for prepared stems. And next time you have to configure it again. That's if you are not caught off guard in the middle of a gig wondering why your saved stems don't load / work.
PS: This is not a debate. It's a discussion to see if there's any protentional way to implement this without causing issues to the rest users (as I mentioned in my first sentence)
Because this way of thinking makes things far more complicated for the vast majority of users (that don't really copy/move settings.xml between multiple systems) in order to potentially "ease" just a few.
The software should not produce "unexpected" behavior.
For any software, if I (as a user) set a setting, I want it to stay there. That's why settings exist. Having the software "check" the user settings and readjust them on every launch defeats that purpose of having a setting IMHO.
Maybe an action (that you would launch manually by yourself) that would "check" and validate settings could be a better option.
Finally imagine the hassle of getting a "report" every time you start VirtualDJ. Most users would not even read what it says and they would just click ok.
Or imagine that you have set to have your prepared stems saved on an external HDD and you start the program (by mistake or just for a quick irrelevant task) without the external connected.
Boom! Out the door goes your saved path for prepared stems. And next time you have to configure it again. That's if you are not caught off guard in the middle of a gig wondering why your saved stems don't load / work.
PS: This is not a debate. It's a discussion to see if there's any protentional way to implement this without causing issues to the rest users (as I mentioned in my first sentence)
I fully agree on the not changing default/having hidden behaviour. Another fact here is, there are cases where the setting fhst exists cannot be applied...if you keep those then the default behaviour is undefined from a high level.
That's why I was suggesting VirtualDJ inform the user of what is happening...I only gain that you don't like the auto demotion/adjustment of settings and then reporting, you favour reporting these problems immediately with a manual intervention step and then saving the result (please correct me if I'm wrong).
Mind you, making a user manually adjust new settings it is achieving the same thing, it's just that you have to start from a default state, instead of an almost ready state.
Inviato Fri 04 Aug 23 @ 1:56 pm