I reported as regression, I sent out PM, and still have no clue why this has changed and maybe you don't either. It effects the way I need to determine if I am on a master or not and so now broke in 2090 for TM and TV.
HRESULT hr = GetInfo ("get_deck 'master' ? true : false",&query);
When on master, hr == S_OK, query == 0.0 with build 2090.
With builds 2087 and previous thousand builds or so, hr == S_OK and query == 1.0 with same syntax.
With build 2090 and still on master,
hr = GetInfo ("get_deck",&query);
hr == S_OK and query == 1.0
Going back to 2087 and all is good with the above syntax.
HRESULT hr = GetInfo ("get_deck 'master' ? true : false",&query);
When on master, hr == S_OK, query == 0.0 with build 2090.
With builds 2087 and previous thousand builds or so, hr == S_OK and query == 1.0 with same syntax.
With build 2090 and still on master,
hr = GetInfo ("get_deck",&query);
hr == S_OK and query == 1.0
Going back to 2087 and all is good with the above syntax.
Posted Thu 18 Dec 14 @ 3:43 pm
It's actually in the change log:
-Actions from master plugin apply to active deck instead of master deck by default
But as it does interfere with checking if you are on the master deck, this change will be reverted until a better solution is found.
-Actions from master plugin apply to active deck instead of master deck by default
But as it does interfere with checking if you are on the master deck, this change will be reverted until a better solution is found.
Posted Fri 19 Dec 14 @ 3:17 am
Not sure I know what it means that actions from master deck apply to active deck and I don't believe it is reported in the change log that this breaks the ability to determine if you are on a master (the most important thing).
There are only 2 things important for me in this regard.
1) I need to know where the hell it is. On master or on what deck and with 2090 cannot tell if on master so it will come up as on a deck.
2) signals such as activate and UI up or down and these apply to master if indeed on master and not to some active deck.
I don't care what the syntax is for determining on the master, but you have a whole line of builds being used by various people that uses the above syntax. I have some updates and waiting on a resolution for this one way or another.
Thanks
There are only 2 things important for me in this regard.
1) I need to know where the hell it is. On master or on what deck and with 2090 cannot tell if on master so it will come up as on a deck.
2) signals such as activate and UI up or down and these apply to master if indeed on master and not to some active deck.
I don't care what the syntax is for determining on the master, but you have a whole line of builds being used by various people that uses the above syntax. I have some updates and waiting on a resolution for this one way or another.
Thanks
Posted Fri 19 Dec 14 @ 7:17 am
By the way, I don't relish the thought of having code like:
if in build abc, do it one way, and if in build xyz, do it another way.
if in build abc, do it one way, and if in build xyz, do it another way.
Posted Fri 19 Dec 14 @ 8:42 am
Wait a minute!! So you mean to tell me that any effect I assign as "master" will basically be assigned to a deck which in short means there's really NO EFFECTS ON THE MASTER ANYMORE?!?!?
If this is true what A LOAD OF CRAP!!
If this is true what A LOAD OF CRAP!!
Posted Fri 19 Dec 14 @ 4:04 pm
Adion wrote :
But as it does interfere with checking if you are on the master deck, this change will be reverted until a better solution is found.
I already said the change will be reverted, because it breaks some functionality as you said... That's why we have beta versions.
Beatbreaker: That's not what it means at all.
Let me explain further what was changed and why then...
Plugins can execute actions or request info through actions from virtual dj using GetInfo and SendCommand.
Usually you don't specify a deck with this, and it is executed on the deck the effect is executed from.
If your effect is running on the master output, there is however no specific deck that these actions operate on, so one has to be chosen.
In the builds before this was the 'master' deck, which is the deck manually selected as master (in the default skins by using the A, B, C, D buttons on each deck, or selected automatically when you load a new track.
Beta 2090 changed this so that instead of the master deck, it operated on the active deck. The active deck is the loudest deck currently playing.
This makes more sense since effects operating on the master output operate mainly on what audio or visual comes from the active deck, whereas the master deck would be the deck that you are cueing up but is not necessarily playing yet.
It also solves a discrepancy since the SongBPM and SongPosBeats parameters passed to the plugin already came from the active deck rather than the master deck.
The problem with this however, as Don found out, is that unfortunately (also because of backward compatibility, so too late to change) the 'master' syntax is used both to indicate the master output and the master deck.
So, as said before, this change will be reverted. Plugin authors can work around this using something like "get_deck 'master' ? deck active my_action : my_action"
Posted Sat 20 Dec 14 @ 12:36 am
Adion wrote :
It's actually in the change log:
-Actions from master plugin apply to active deck instead of master deck by default
-Actions from master plugin apply to active deck instead of master deck by default
I was more responding to the above like this was supposed to be some kind of explanation. Even after your 'clarification', in practice I don't think I would know how it is supposed to work without seeing it in action but I don't have the time to dwell on that.
With the betas, your damned if you do and damned if you don't :) Since the betas are downloaded often and when a problem like this arises, I have to spend additional time trying to explain it to others. Each time a new beta comes in, I run some initial test to see what might be broken as it might effect me and so I can explain things. Then make an attempt at reporting it and can only hope it will be acknowledged and fixed. I first reported this as a regression and then a PM but with no response, so I also reported it here. Days have gone by now and in the meantime things are broken requiring me to make more explanations. Your going to have problems sure, but this is something fundamental to how the program is supposed to work. Did you think this thru before you decided to throw it out there to see if it sticks? Clearly was not tested to any degree.
I have spent an enormous amount of time with VDJ8 problems as others have as well. It does not matter if it is a beta or a so called release build because they are equally a problem. With the betas we are grasping for fixes.
Waiting on an update.
Posted Sat 20 Dec 14 @ 6:02 am
Just a note that this appears to be fixed in build 2094.
Posted Mon 22 Dec 14 @ 5:25 am