Adion
beatbreaker1 wrote :
I have a few VST's, the camera plugin as Don has mentioned (I have 2 that are setup on opposite sides of my decks) and a few others.
My thread asking why they weren't saved was not all that long ago.
This is needed.....
My thread asking why they weren't saved was not all that long ago.
This is needed.....
Can you expand on the vst's? The camera I understand, but how do you have a vst that you set up differently on deck 1 and 2?
Posted Mon 26 Oct 15 @ 4:25 pm
the SOUND INSURGENT
One vst is for the post fader fx's. I have to set the crossfader differently for each deck (left/right). Another plugin is for the mixer, when turning the bass, treb, mids. I have different colors for each deck.
Posted Mon 26 Oct 15 @ 7:17 pm
PachN
Something similar here.
Using the Flanged Loop Out effect, the values I set the sliders to ARE stored across session, and differently for deck 1 and 2 too.
BUT, the values are not applied on the next session. I have to move all sliders to apply their values for the effect.
Using the Flanged Loop Out effect, the values I set the sliders to ARE stored across session, and differently for deck 1 and 2 too.
BUT, the values are not applied on the next session. I have to move all sliders to apply their values for the effect.
Posted Mon 26 Oct 15 @ 7:30 pm
Don Moir
So who knows where this will go. Silence is not golden in this case.
To restate on what to do with user interfaces and saving of data:
1) some think it should be the data is saved per deck or master. This is the thing that makes the most sense, especially since you are given an interface that says deck 1 or deck 2 or master.
2) Atomix feels like it is ok to overwrite the user settings and only save the settings set on the one you last changed. If you had settings for deck 1 and then you change in deck 2, on next reload the settings that were in effect for deck 1 have been replaced from the settings in deck 2.
3) some do not know what is going on and since they are high most of the time everything appears normal :)
In comes audio only visualizations with no home on the skin so it gets moved around from deck to deck which can break things and cause confusion. About 6 months ago I posted about this. I was told it exist internally. I was told this and that. So I put together something that could work as a visualization that made sense. Assuming the VDJ interface made sense when it came to audio only vis which still at least 6 months later does not. So in last few days I revisited everything about this. I still don't have an absolute answer. If all this was straight forward we would not be talking about it now.
Detection of audio only vis is not absolute but can make ball park guess of it. There is some difficulty when you are no longer the vis with this etc. It could be so easy but isn't.
I have TellyMediaV running as audio only vis. It is on master. You can see below that TellyMediaV is also active on the left deck and right deck. It will be shown active on master as well. Then is only one real active instance though. You can also see the interface buttons are at minus indicating the interface is up for each. Then you will notice there is only one interface up called visualization. Internally TM is tracking all instances and making it behave as expected. Expected behavior is open to interpretation currently :) You will notice the dials are not set on the right deck but that is no big deal and just did not bother with it for now. Knowing that it is a visualization means I can automatically disable any audio as well if any. In this case TM does not care where the hell VDJ thinks it should be. It is forcing compliance which it should not have to do.
Just to let you know I am trying to think of something to do with it. Not sure above is going to cut it but doing something rather than nothing.
To restate on what to do with user interfaces and saving of data:
1) some think it should be the data is saved per deck or master. This is the thing that makes the most sense, especially since you are given an interface that says deck 1 or deck 2 or master.
2) Atomix feels like it is ok to overwrite the user settings and only save the settings set on the one you last changed. If you had settings for deck 1 and then you change in deck 2, on next reload the settings that were in effect for deck 1 have been replaced from the settings in deck 2.
3) some do not know what is going on and since they are high most of the time everything appears normal :)
In comes audio only visualizations with no home on the skin so it gets moved around from deck to deck which can break things and cause confusion. About 6 months ago I posted about this. I was told it exist internally. I was told this and that. So I put together something that could work as a visualization that made sense. Assuming the VDJ interface made sense when it came to audio only vis which still at least 6 months later does not. So in last few days I revisited everything about this. I still don't have an absolute answer. If all this was straight forward we would not be talking about it now.
Detection of audio only vis is not absolute but can make ball park guess of it. There is some difficulty when you are no longer the vis with this etc. It could be so easy but isn't.
I have TellyMediaV running as audio only vis. It is on master. You can see below that TellyMediaV is also active on the left deck and right deck. It will be shown active on master as well. Then is only one real active instance though. You can also see the interface buttons are at minus indicating the interface is up for each. Then you will notice there is only one interface up called visualization. Internally TM is tracking all instances and making it behave as expected. Expected behavior is open to interpretation currently :) You will notice the dials are not set on the right deck but that is no big deal and just did not bother with it for now. Knowing that it is a visualization means I can automatically disable any audio as well if any. In this case TM does not care where the hell VDJ thinks it should be. It is forcing compliance which it should not have to do.
Just to let you know I am trying to think of something to do with it. Not sure above is going to cut it but doing something rather than nothing.
Posted Tue 27 Oct 15 @ 4:17 pm
SBDJ
I have added to the next build a new script command 'is_audioonlyvisualisation' which will return true if the deck has the active audio only visualisation instance.
Posted Tue 27 Oct 15 @ 8:28 pm
tayla
Erm, could you translate that into dumb schmuck for me please and anyone else that's not sure of what it means... I'm not even gonna say what I think it means, lol.
Posted Tue 27 Oct 15 @ 8:36 pm
Don Moir
SBDJ wrote :
I have added to the next build a new script command 'is_audioonlyvisualisation' which will return true if the deck has the active audio only visualisation instance.
That is the easily part when the audio only vis is active so not sure that will do much good. I mean pretty easy to determine what slot it is supposed to be in so above does not do anything that helps. The problem is it needs a home just like the master and decks are homes (slots) for normal effects. Then you could have script that identifies an instance in the audio_only_vis slot. Adding 'is_audioonlyvisualisation' does not address the confusion of it bouncing around either. It's currently moving around knocking things out of slots, making interfaces disappear, etc.
The way it is now it can be loosely identified by GetStringInfo ("setting 'videoAudioOnlyVisualisation'",...,...) and then when it is active you can identify it in OnDraw. You need to know it before that and a real slot on the skin does that. That is, it no longer will need to act like it's a chicken with it's head cut off.
Posted Tue 27 Oct 15 @ 9:02 pm
SBDJ
Don Moir wrote :
Detection of audio only vis is not absolute but can make ball park guess of it. There is some difficulty when you are no longer the vis with this etc. It could be so easy but isn't.
You complained that detection is not absolute. Now it is.
In any case it was actually added to make it easy for it to be used in script, rather than requiring messing around with a bunch of conditionals.
Don Moir wrote :
The problem is it needs a home just like the master and decks are homes (slots) for normal effects. Then you could have script that identifies an instance in the audio_only_vis slot.
It has a dedicated script slot already. Has done for ages. Like I said it hasn't been done on the skin as yet. It was however documented and can be used now. Some skin developers have already incorporated it.
Don Moir wrote :
Adding 'is_audioonlyvisualisation' does not address the confusion of it bouncing around either. It's currently moving around knocking things out of slots, making interfaces disappear, etc.
It wasn't supposed to address that obviously.
Posted Tue 27 Oct 15 @ 10:36 pm
Don Moir
SBDJ wrote :
It has a dedicated script slot already. Has done for ages. Like I said it hasn't been done on the skin as yet. It was however documented and can be used now. Some skin developers have already incorporated it.
Rather pointless to have it if skin does not support it like the default skins that many use. What skin has it? Where is it documented? If it "Has done for ages" why have the default skins not been updated for ages?
SBDJ wrote :
It wasn't supposed to address that obviously.
Don Moir wrote :
Adding 'is_audioonlyvisualisation' does not address the confusion of it bouncing around either. It's currently moving around knocking things out of slots, making interfaces disappear, etc.
It wasn't supposed to address that obviously.
Obviously my point was that is the real problem.
Posted Tue 27 Oct 15 @ 10:57 pm
Adion
The slot is called "audioonlyvisualisation", so on all of the effect_* actions, you can use that instead of the slot number.
effect_show_gui "audioonlyvisualisation"
effect_select "audioonlyvisualisation"
etc...
Not every feature that vdj offers is included in the default skin, but that doesn't mean the feature is useless.
effect_show_gui "audioonlyvisualisation"
effect_select "audioonlyvisualisation"
etc...
Not every feature that vdj offers is included in the default skin, but that doesn't mean the feature is useless.
Posted Wed 28 Oct 15 @ 5:21 am
gabycorrea
Hi Don, I see you have loops that you send
you will have a problem ??
Cheers
Posted Wed 28 Oct 15 @ 3:03 pm
Don Moir
Gabriel is not necessary to keep posting crash reports... It has been identified. I will be sending you something to test with when the confusion factor can be cleared up
Posted Wed 28 Oct 15 @ 3:53 pm
Don Moir
Adion wrote :
The slot is called "audioonlyvisualisation", so on all of the effect_* actions, you can use that instead of the slot number.
effect_show_gui "audioonlyvisualisation"
effect_select "audioonlyvisualisation"
etc...
Not every feature that vdj offers is included in the default skin, but that doesn't mean the feature is useless.
effect_show_gui "audioonlyvisualisation"
effect_select "audioonlyvisualisation"
etc...
Not every feature that vdj offers is included in the default skin, but that doesn't mean the feature is useless.
I see. I was thinking you might be adding something to clear up the confusion and fix things which we have been talking about and adding buttons or creating custom ones for audio only vis for selection etc. does not fix anything. I think it adds to the confusion actually. effect_show_gui "audioonlyvisualisation" does nothing if the audio only vis is not active. On default skins you can add custom buttons to a deck only as far as I can tell so using them to bring up the audio only vis GUI on the master or other deck does not make much sense. So have been trying to state the following forever.
Without something like this it appears to me it will remain as is with the audio only vis bouncing around, user confusion with trying to deactivate a audio only vis, confusion when the UI just disappears from VDJ user interface, confusion that it looks just like any effect selected and manipulated by user, and confusion about deck specific data and what all that means with an audio only vis. This here makes it on par with a TRUE deck slot for decks or master. I suspect now there will be no effort to change the confusion factors. This would not be on a deck etc but play a central role on the skin. With this user would know not to deactivate (or could do something intelligent) and it could be colored different as an indication. Also right in your face so easy to change them out or select none. Internal code could make better heads or tails out of it.
Posted Wed 28 Oct 15 @ 4:31 pm
SBDJ
As I said before there are no plans to change the fact that the plugin will relocate as required.
I do agree it would be nice for it to have a home on the skin somewhere and have requested it myself in the past.
I do agree it would be nice for it to have a home on the skin somewhere and have requested it myself in the past.
Posted Wed 28 Oct 15 @ 5:36 pm
Don Moir
Yeah I think a poor design with no thought. With very little work the vis slot could be made compact, indicate what deck or master it is active on, and other things pretty easy... I do realize where we are at now with the whole thing and periodic confirmation can be good. Six months ago I was under the impression things would change for the better in this regard. Really kind of a mess dealing with this internally unless you just do it the VDJ way which is also a mess :) Not trying to be obstinate, just trying to make it make sense and move on.
Should I send you a bill anytime someone is confused by it and I need to try and explain it ?
Should I send you a bill anytime someone is confused by it and I need to try and explain it ?
Posted Wed 28 Oct 15 @ 6:01 pm
SBDJ
I'm hoping that was an attempt at humour ;)
Posted Wed 28 Oct 15 @ 9:10 pm
Don Moir
half and half. I wonder how many man hours have been wasted due to lack of proper professional testing.
Posted Thu 29 Oct 15 @ 7:54 am
discobrian24
Honestly I just want my previews to match what should be there, ie. video on one, audio only Milkdrop on 2.
Posted Fri 30 Oct 15 @ 7:58 am
SBDJ
Which is what happens now. If you have a video on 1, the audio vis will show on 2.
Posted Fri 30 Oct 15 @ 9:30 am
Don Moir
So moving along...
I have TM working and controlling the visualization in an attempt to make it make sense. When TM is detected as a visualization (with some hand waving) it only allows one interface for it and disallows activating it from the user interface (either TM user interface or VDJ user interface). Activation is automatic depending on the rules provided for that by VDJ and makes no sense to try and activate or deactivate an audio only vis on a deck or master or where ever it is. If you do try to activate TM when it is running as audio only vis, it will essentially do nothing. It will blink on momentarily but deactivate right away if it is not the true visualization instance. The true visualization instance simply remains active when enabled internally by VDJ and you can't deactivate it from the normal user interface. I am sure that all is as clear as mud :) but using it this way makes the best sense given that audio only vis shares the deck or master slots which makes no sense. It is easier to visualize this then it is to explain it. I have some more work to do with it yet but coming along.
The other thing I am revisiting is what to do about deck or master specific data. To me it is quite clear that if you have an interface for deck 1 or master etc. and you set that data it should be saved for that deck or master. It has been hard to get any kind of consensus of opinion about this. I do know the VDJ way of saving the last thing you set and then changing it for all decks or master next time you run is not intuitive. Not sure that having deck specific data is all that clear either but makes sense if you have an interface for it. I could have a single interface per named effect no matter where it is run. This is the easiest to understand. You can always make copies of TM if you want special data for it. Part of the rational for having deck specific data came from the fact that native effects cannot be copied. So surely they would have deck specific data for them I am thinking at the time. Also seems like an easy way to have specific data without making copies. It was kind of hard to figure out what was a bug and what was not in the beginning and these kind of things seemed like minor issues at the time.
Would be nice to get more feedback about deck specific data so please chime in on that.
I have TM working and controlling the visualization in an attempt to make it make sense. When TM is detected as a visualization (with some hand waving) it only allows one interface for it and disallows activating it from the user interface (either TM user interface or VDJ user interface). Activation is automatic depending on the rules provided for that by VDJ and makes no sense to try and activate or deactivate an audio only vis on a deck or master or where ever it is. If you do try to activate TM when it is running as audio only vis, it will essentially do nothing. It will blink on momentarily but deactivate right away if it is not the true visualization instance. The true visualization instance simply remains active when enabled internally by VDJ and you can't deactivate it from the normal user interface. I am sure that all is as clear as mud :) but using it this way makes the best sense given that audio only vis shares the deck or master slots which makes no sense. It is easier to visualize this then it is to explain it. I have some more work to do with it yet but coming along.
The other thing I am revisiting is what to do about deck or master specific data. To me it is quite clear that if you have an interface for deck 1 or master etc. and you set that data it should be saved for that deck or master. It has been hard to get any kind of consensus of opinion about this. I do know the VDJ way of saving the last thing you set and then changing it for all decks or master next time you run is not intuitive. Not sure that having deck specific data is all that clear either but makes sense if you have an interface for it. I could have a single interface per named effect no matter where it is run. This is the easiest to understand. You can always make copies of TM if you want special data for it. Part of the rational for having deck specific data came from the fact that native effects cannot be copied. So surely they would have deck specific data for them I am thinking at the time. Also seems like an easy way to have specific data without making copies. It was kind of hard to figure out what was a bug and what was not in the beginning and these kind of things seemed like minor issues at the time.
Would be nice to get more feedback about deck specific data so please chime in on that.
Posted Sat 31 Oct 15 @ 12:23 pm
