Don Moir
I have mentioned these things before and was led to believe that they would be addressed.
1) When plugin is running as a visualization, GetInfo ("get_deck 'master' ? true : false",&query); always returns true. This means it is impossible for me to determine if effect is running as a visualization unless you have added some other script for it.
2) Why do you move the visualization from deck to deck or to master as videos are added or removed? User has to hunt it down to find the interface for it lol. There is more weirdness with this.
3) If you had a visible skin slot for visualizations, then that would help clean things up a lot I would think but then all skins need to be updated. Will there be a visible skin slot for visualizations?
There is more to the story but please answer above first.
Let me add that trying to activate a visualization manually still causes OnStop and OnStart to be called. Do you not know it is a visualization and you should nothing when uses does this?
1) When plugin is running as a visualization, GetInfo ("get_deck 'master' ? true : false",&query); always returns true. This means it is impossible for me to determine if effect is running as a visualization unless you have added some other script for it.
2) Why do you move the visualization from deck to deck or to master as videos are added or removed? User has to hunt it down to find the interface for it lol. There is more weirdness with this.
3) If you had a visible skin slot for visualizations, then that would help clean things up a lot I would think but then all skins need to be updated. Will there be a visible skin slot for visualizations?
There is more to the story but please answer above first.
Let me add that trying to activate a visualization manually still causes OnStop and OnStart to be called. Do you not know it is a visualization and you should nothing when uses does this?
Posted Tue 26 May 15 @ 12:13 pm
Adion
1. Not sure what you expected. Just tried and "get_deck 'master' ? true : false" returns true when the effect is running on the master (affecting all decks) and false if it is running on a specific deck. (affecting just that deck)
It is indeed not useful to determine if a plugin is running as a visualisation or not.
get_effect_name "audioonlyvisualisation" will give you the name of the currently active visualisation.
This does not 100% guarantee that the instance you query from is that instance though.
2. It moves so that transitions from mixing video to mixing audio are as seamless as possible. (When going from a deck with video to a deck with audio, the chosen transition can be used to transition from video to visualisation.
Then when both decks are running audio, it has to move to the master, since otherwise the plugin would need to run on both decks, with a probably useless transition between 2 of the same plugins.
3. An easier way to open the config of the visualisation would indeed be useful. It will probably be added to the config window at least, since that's where you select the visualisation.
For skins the actions are there, but I think currently not used yet by most plugins:
effect_show_gui "audioonlyvisualisation" can be used to open the editor, but all other effect actions can be used with "audioonlyvisualisation" as slot parameter as well.
It is indeed not useful to determine if a plugin is running as a visualisation or not.
get_effect_name "audioonlyvisualisation" will give you the name of the currently active visualisation.
This does not 100% guarantee that the instance you query from is that instance though.
2. It moves so that transitions from mixing video to mixing audio are as seamless as possible. (When going from a deck with video to a deck with audio, the chosen transition can be used to transition from video to visualisation.
Then when both decks are running audio, it has to move to the master, since otherwise the plugin would need to run on both decks, with a probably useless transition between 2 of the same plugins.
3. An easier way to open the config of the visualisation would indeed be useful. It will probably be added to the config window at least, since that's where you select the visualisation.
For skins the actions are there, but I think currently not used yet by most plugins:
effect_show_gui "audioonlyvisualisation" can be used to open the editor, but all other effect actions can be used with "audioonlyvisualisation" as slot parameter as well.
Posted Wed 27 May 15 @ 10:28 am
Don Moir
Adion wrote :
1. Not sure what you expected. Just tried and "get_deck 'master' ? true : false" returns true when the effect is running on the master (affecting all decks) and false if it is running on a specific deck. (affecting just that deck)
When running as an audioOnlyvisualization, I am seeing HRESULT as always S_OK and query as always 1. Running XP with build 2282. Starting fresh, load video onto deck 1 or 2, set break point in OnLoad, do get master. Always returning TRUE for me when the visualization is clearly on a deck. When not running as an audioOnlyvisualization, get master works as expected.
Adion wrote :
It is indeed not useful to determine if a plugin is running as a visualisation or not.
Well this is a long story and why I limited the original post. Not counting audioOnlyVis at the moment and Just looking at the case where you have deck1, deck2, etc., and master. For each of these you have a potential user interface and when those interfaces are brought into view they are labeled appropriately to the corresponding deck or master. For me, I decided to make these user interfaces deck or master specific because it makes sense to do so since there is a separate interface for each. The other thing that would make sense is to only have one interface but then that limits things somewhat and this one interface would need to control all instances that may be running. Most other plugins do nothing about this and so user is left confused when they change things on say one deck and it is not reflected later when they bring up the user interface. (more on this if you need more on this :)
Now in comes audioOnlyVisualization, what does it's user interface correspond to? Well if I knew it was running as an audioOnlyVis then that solves that problem.
The whole thing about what instance corresponds to what user interface is indeed confusing no matter how you slice it. What is your view on this? The way you have it now, the user interface is chasing between decks, effects disappear from slot on next run, user interfaces either disappear or you change the deck master association on the fly. All this very confusing and unexpected behavior.
Adion wrote :
get_effect_name "audioonlyvisualisation" will give you the name of the currently active visualisation.
This does not 100% guarantee that the instance you query from is that instance though.
of the same plugins.
This does not 100% guarantee that the instance you query from is that instance though.
of the same plugins.
I use this and if get master was working for me then I believe it is 100 percent. This is in addition to determining if there is video on decks 1 or 2 and a couple other things.
Posted Wed 27 May 15 @ 12:14 pm
Don Moir
Too much detail in all this so breaking it up in separate post.
The way it is now is it's sharing with a deck or master slot which just leads to confusion and unexpected behavior. A skin slot for audioOnlyVis would solve this I think but then skins need to be updated. If you do something with it in config I am not sure how user friendly that would be. I think main thing is stop sharing audioOnlyVis with a deck or master skin slot.
Adion wrote :
3. An easier way to open the config of the visualisation would indeed be useful. It will probably be added to the config window at least, since that's where you select the visualisation.
For skins the actions are there, but I think currently not used yet by most plugins:
effect_show_gui "audioonlyvisualisation" can be used to open the editor, but all other effect actions can be used with "audioonlyvisualisation" as slot parameter as well.
For skins the actions are there, but I think currently not used yet by most plugins:
effect_show_gui "audioonlyvisualisation" can be used to open the editor, but all other effect actions can be used with "audioonlyvisualisation" as slot parameter as well.
The way it is now is it's sharing with a deck or master slot which just leads to confusion and unexpected behavior. A skin slot for audioOnlyVis would solve this I think but then skins need to be updated. If you do something with it in config I am not sure how user friendly that would be. I think main thing is stop sharing audioOnlyVis with a deck or master skin slot.
Posted Wed 27 May 15 @ 12:30 pm
Don Moir
Any word on the above? Adion mentioned get master works for him and it works for me too when not using and audioOnlyVis, but he did not mention if that is what he is getting when using an audioOnlyVis.
To clarify, in my case I have deck / master specific data and I suppose that needs to extend to audioOnlyVis specific data. The way you have it seems to be the only thing that makes sense. Otherwise you have other problems and confusion. The whole thing with what interface belongs to what data seems to be a mess. Again, do you have any rational for this?
To clarify, in my case I have deck / master specific data and I suppose that needs to extend to audioOnlyVis specific data. The way you have it seems to be the only thing that makes sense. Otherwise you have other problems and confusion. The whole thing with what interface belongs to what data seems to be a mess. Again, do you have any rational for this?
Posted Mon 01 Jun 15 @ 8:37 am
Adion
As explained, the audioOnlyVis dynamically switches from decks to master and back, so in terms of loading settings it doesn't make much sense to have it do different things on decks or on master. Since it dynamically changes querying only in OnLoad is not very useful for an audioOnlyVis, you should see the correct deck when called from OnDraw though.
Posted Mon 01 Jun 15 @ 11:42 am
Don Moir
Adion wrote :
As explained, the audioOnlyVis dynamically switches from decks to master and back, so in terms of loading settings it doesn't make much sense to have it do different things on decks or on master.
That is correct and if you could tell it was an audioOnlyVis then you could load a single instance of the data for it and you would not care what deck or master it might be on.
The problem goes deeper than this. Take audioOnlyVis out of it for a moment. I will use your Slideshow effect as an example but this applies to most of the VDJ effects. It has a user interface for deck1, deck2, etc. and master. Suppose I want to set the path for it's images on deck 1. Ok fine, bring up the UI and click select. Now suppose I want to set the path for Slideshow on deck 2. Ok bring up the UI for Slideshow on deck 2 and click select. Now deck1 Slideshow and deck2 Slideshow have different paths. Shut down VDJ. Bring it back up. Neither of the paths were saved for Slideshow. Why? Apparently you have to set the same path for all loaded Slideshow instances in order for it to save which is completely counter intuitive. Most effects have no deck specific data and they are just at wim of whatever VDJ thinks their data should be I guess. Who would know and I guess the VDJ auto save feature is handling this. Is this not confusing to you ? Suppose you wanted a different camera on deck 1 versus deck 2, well you can't have it using your camera effect. Although running some effects on a deck is useless since they can be scaled badly.
Ok bring back audioOnlyvisualizations. I want to set some data for it. What path should be used for it? What deck or master is it on where I can set the data? Nobody really knows. I know now because I have dug thru this mess.
I guess you now agree that get master does not work for audioOnlyVisualizations except in OnDraw. Gee what if I wanted to set that data for it before I activated it. Well get master does not work in OnGetUserInterface for an audioOnlyVisualizations which makes that unusable for deck specific data. audioOnlyVis have no home and no where to set specific data for them. I take it in OnLoad you do not know it is an audioOnlyVis or something like that. You must know something because you know enough that get master does not work like it does for a normal effect.
1) most VDJ effects do not have deck specific data. VDJ is happy to confuse the user with multiple interfaces that seem like they do have deck specific data but they don't and even worse since they might not save anything you just set.
2) audioOnlyVis looks like it is just shoe horned in there and still goofy. It has gotten better since day 1 where it was badly broke and a few other times where it got broke but it is still broken. I guess you think it is solid with all the goofy behavior and there is more that I am just too tired of it to explain and this is probably going out to deaf ears anyway.
3) I followed your lead with multiple interfaces for each deck. Hell why would they have an interface for each if they were not deck specific. Surely they would not leave it as confusing as it is so it must be broken I am thinking. I think you, if you even thought about it at all, may have though just do it that way... They will be so confused they think they are doing something wrong and will never figure it out and you might be right about that since no one probably really knows how it supposed to work but I doubt it even got that much thought. For TM and TV and made it have deck or master specific data because it is the only thing that makes sense (expect maybe to you).
There are only 2 things that make sense with this. Have deck specific data or have one interface that controls all instances. Neither one is that attractive and clearly the path you took is probably the worse.
Posted Mon 01 Jun 15 @ 9:08 pm
Don Moir
So I take it do to lack of any real response that this situation will not change in VDJ8.
To restate the situation is this:
1) You have multiple interfaces for each deck or master but this does not really work for most VDJ effects. User is left wondering why it does not work in some cases.
2) audioOnlyVisualizations have no deck specific data and move from place to place. That would be fine if you could determine that you were running as an audioOnlyVis and then you could bring up and audioOnlyVis user interface. But determining if you are running as an audioOnlyVis does not work when it is needed like when user needs to bring up the interface for it although this info is available in OnDraw but that is too late.
3) audioOnlyVisualizations have no visible skin slot and looks like they never will.
All this multiple interface thing has really never set well with me. It just adds to confusion but it does give you additional flexibility. I followed your lead on that and assumed you would fix the broken parts for effects made by Atomix.
So where does this leave me? The easiest thing I think from the users perspective is to have a single data stream for a given named effect. This also solves the problem with audioOnlyVis since it now will not care if audioOnlyVis or not. The problem with this is internally you will have a single user interface controlling possibly more than on instance of the effect. It is bound to be a little tricky to do that but manageable.
I wish someone would comment on the above before I go on to another implementation of this. If you say you already commented, well you commented but with no relevant information :)
To restate the situation is this:
1) You have multiple interfaces for each deck or master but this does not really work for most VDJ effects. User is left wondering why it does not work in some cases.
2) audioOnlyVisualizations have no deck specific data and move from place to place. That would be fine if you could determine that you were running as an audioOnlyVis and then you could bring up and audioOnlyVis user interface. But determining if you are running as an audioOnlyVis does not work when it is needed like when user needs to bring up the interface for it although this info is available in OnDraw but that is too late.
3) audioOnlyVisualizations have no visible skin slot and looks like they never will.
All this multiple interface thing has really never set well with me. It just adds to confusion but it does give you additional flexibility. I followed your lead on that and assumed you would fix the broken parts for effects made by Atomix.
So where does this leave me? The easiest thing I think from the users perspective is to have a single data stream for a given named effect. This also solves the problem with audioOnlyVis since it now will not care if audioOnlyVis or not. The problem with this is internally you will have a single user interface controlling possibly more than on instance of the effect. It is bound to be a little tricky to do that but manageable.
I wish someone would comment on the above before I go on to another implementation of this. If you say you already commented, well you commented but with no relevant information :)
Posted Sat 06 Jun 15 @ 9:07 am
SBDJ
There is no way to tell your plugin that it is the visualisation in OnLoad, since under certain circumstances an existing plug in instance can be converted to an audio only instance.
I think the best thing for you Don is to work within the framework given for what is best for you and your users.
Most users however are not running multiple configurations for a visual plug in across multiple instances.
I think the best thing for you Don is to work within the framework given for what is best for you and your users.
Most users however are not running multiple configurations for a visual plug in across multiple instances.
Posted Sat 06 Jun 15 @ 11:50 am
Don Moir
Thanks for replying Scott.
That is due to lack of design. I think if audioOnlyVis was treated as a special kind of 'deck' with it's own drop down list etc., it would resolve this. You have to know this leads to odd behavior with effects disappearing from the slot among other things. It is what it is but I think this and the multiple interface thing needs to be looked again for possibly next main version of VDJ8.
Always and Atomix should be trying to do the same, but in this case what is the framework? You have to say the framework is broken. Early on there were questions and confusion about setting data for an effect. It led to me using deck specific data. Early on it was hard to determine for some things what was broken and what was designed behavior :) I can't find the thread about this that I really wanted but here is another one that relates confusion.
http://www.virtualdj.com/forums/201219/VirtualDJ_8_bug-report_Forum/FX_s_Reset_When_I_Close_Open____________.html?search=deck%20specific&page=1
The stuff I tend to report or act on is normally reported by end users first. Users will do anything the program allows them to do and there is confusion when something does not work as expected. Without hardly trying, I can think of about 5 things that should be on the 'don't to that list' and at least 2 causes crashes or hangs. This list would contain things that you can do but not handled correctly by VDJ. I don't think you want to document such a list but I think you would want to address the problems.
o - for most effects from atomix, if you change the settings and you have more than one instance running they will not save. They do save if you set the settings to the same thing for each instance I believe. This is easy to run into. If you have an audioAudioVis and do ctrl V so it's on master and you happen to be looking at the interface on deck 2 for same plugin the settings do not take effect next time you run VDJ nor does it change audioVis data which may be on deck 2 as soon as you load a video. You have 2 instances running one hidden on master and one on deck 2 so it does not save.
o - do not try to deactivate an audioOnlyVis. You can and no real harm but since it looks like any other effect who is to know you can't deactivate it. User tries to deactivate and it does not deactivate which is not user expectation. Also stop and start still called when you try to deactivate. Why? You must know it is audioOnlyVis by this time but it should be colored different rather than looking identical to a normal effect and do nothing when user tries to deactivate.
o - As the audioOnlyVis moves from deck to deck, user interfaces for it can disappear and it will be removed from the skin slot which is unexpected behavior.
From my view the only thing that fixes problems with audioOnlyVis is to have a special skin slot and deck type of audioOnlyVis that does not share with decks or master. You might have other thoughts but the way it is now is not at all clean or expected.
SBDJ wrote :
There is no way to tell your plugin that it is the visualisation in OnLoad, since under certain circumstances an existing plug in instance can be converted to an audio only instance.
That is due to lack of design. I think if audioOnlyVis was treated as a special kind of 'deck' with it's own drop down list etc., it would resolve this. You have to know this leads to odd behavior with effects disappearing from the slot among other things. It is what it is but I think this and the multiple interface thing needs to be looked again for possibly next main version of VDJ8.
SBDJ wrote :
I think the best thing for you Don is to work within the framework given for what is best for you and your users.
Always and Atomix should be trying to do the same, but in this case what is the framework? You have to say the framework is broken. Early on there were questions and confusion about setting data for an effect. It led to me using deck specific data. Early on it was hard to determine for some things what was broken and what was designed behavior :) I can't find the thread about this that I really wanted but here is another one that relates confusion.
http://www.virtualdj.com/forums/201219/VirtualDJ_8_bug-report_Forum/FX_s_Reset_When_I_Close_Open____________.html?search=deck%20specific&page=1
SBDJ wrote :
Most users however are not running multiple configurations for a visual plug in across multiple instances.
The stuff I tend to report or act on is normally reported by end users first. Users will do anything the program allows them to do and there is confusion when something does not work as expected. Without hardly trying, I can think of about 5 things that should be on the 'don't to that list' and at least 2 causes crashes or hangs. This list would contain things that you can do but not handled correctly by VDJ. I don't think you want to document such a list but I think you would want to address the problems.
o - for most effects from atomix, if you change the settings and you have more than one instance running they will not save. They do save if you set the settings to the same thing for each instance I believe. This is easy to run into. If you have an audioAudioVis and do ctrl V so it's on master and you happen to be looking at the interface on deck 2 for same plugin the settings do not take effect next time you run VDJ nor does it change audioVis data which may be on deck 2 as soon as you load a video. You have 2 instances running one hidden on master and one on deck 2 so it does not save.
o - do not try to deactivate an audioOnlyVis. You can and no real harm but since it looks like any other effect who is to know you can't deactivate it. User tries to deactivate and it does not deactivate which is not user expectation. Also stop and start still called when you try to deactivate. Why? You must know it is audioOnlyVis by this time but it should be colored different rather than looking identical to a normal effect and do nothing when user tries to deactivate.
o - As the audioOnlyVis moves from deck to deck, user interfaces for it can disappear and it will be removed from the skin slot which is unexpected behavior.
From my view the only thing that fixes problems with audioOnlyVis is to have a special skin slot and deck type of audioOnlyVis that does not share with decks or master. You might have other thoughts but the way it is now is not at all clean or expected.
Posted Sun 07 Jun 15 @ 1:47 pm
Adion
I think it would help us if you could clarify with some actual use cases you or your users have run into.
The idea of selecting an audioOnlyVis is to have something that works automatically.
You configure it once but then I don't think it would be useful to still have it selected it in an effect slot.
If you wanted to have full manual control all the time why would you select it as audioOnlyVis to begin with?
I'm also wondering when you would want to use the same plugin with different options for decks/master/audioOnlyVis.
My guess is that most plugins are build for doing a specific thing, whereas your plugin is more monolithic and can be used for a wide variety of different purposes.
As for the saving of settings, the way it currently works is that the settings are saved for the instance that is closed last. It is true that it is not intuitive for users to know which instance that is going to be. This should be improved so that the settings of the instance for which parameters have been changed last get saved.
Saving different settings for different decks would also solve this, but I don't think practically you'd want different settings on deck 1 and deck 2 on load.
The idea of selecting an audioOnlyVis is to have something that works automatically.
You configure it once but then I don't think it would be useful to still have it selected it in an effect slot.
If you wanted to have full manual control all the time why would you select it as audioOnlyVis to begin with?
I'm also wondering when you would want to use the same plugin with different options for decks/master/audioOnlyVis.
My guess is that most plugins are build for doing a specific thing, whereas your plugin is more monolithic and can be used for a wide variety of different purposes.
As for the saving of settings, the way it currently works is that the settings are saved for the instance that is closed last. It is true that it is not intuitive for users to know which instance that is going to be. This should be improved so that the settings of the instance for which parameters have been changed last get saved.
Saving different settings for different decks would also solve this, but I don't think practically you'd want different settings on deck 1 and deck 2 on load.
Posted Sun 07 Jun 15 @ 3:44 pm
Don Moir
Adion, I am breaking up my response into different post because there is too much detail in all this. This first part just describes what led to per deck master data. Your other points will be answered in additional post.
Because you designed it that way and is the way you have it set up with multiple interfaces. All effects set the data per deck or master because that is also part of the internal design and VDJ user interface. The difference in what I do is I save this information per deck or master and most other effects do not. The other effects do something totally counter intuitive and not many know what they are doing in this area because it makes no sense to any rational thinking. I mentioned the 'don't do that list'. In my mind, I have also started the 'goofy list'.
That would only be a very minor improvement and this will still be on the 'goofy list'. That is because when the user sets the data, it will work as expected, but the next time it needs to load it may or may not. You will still be over writing what the user set in some cases and user will still not know why. I actually went thru several iterations on how this might work. It is not that I really wanted to save info per deck master, but it is the only thing that makes true deterministic sense the way you have it set up.
Early on looking at this a lot and listening to confusion about why this did not work as expected in the threads there was only one conclusion I could make and this is some of the detail for that.
When I first started with VDJ8, it was clear you had a different user interface for each deck or master. These interfaces change the data for it's instance while it is running. But depending on which way the wind is blowing, the data you set may not be actually be saved. It makes no sense to have different interfaces for each instance if it does not actually work which is the case now for most Atomix effects. An interface either controls all of it's instances with the same data or it has specific data for each instance. In the case of VDJ7, you had a single interface for each named effect and in order to get different interfaces you need to make copies of the effect with a new name which you can still do in 8. So a natural way to get different data sets. In comes VDJ8 with it's multiple interfaces allowing one for each instance and at the time initially deciding what to do about it. I think well it is simpler from a users perspective to have one interface that controls the same named plugin no matter what deck it is on. But then VDJ8 has provided for an interface for each deck or master. I think it is a natural thought to have separate data when you have separate interfaces. Now I did not make the decision based on just multiple interfaces. I am thinking well you don't have to keep renaming the plugin to get new data sets. Also looking at the native plugins they can't be copied so it must be the plan to have different data sets for each instance. So using the native camera effect, even if you set say a camera for one deck and a different camera on another deck it will work for the instance until next time you run VDJ it will no longer have the 2 cameras. Are you suggesting I should have followed this broken pattern? Multiple instances of the effect in a single DLL is really no different then having different named effects. The only issue with saving the data is knowing what deck or master it is on. I did not see it as a real choice. Either make it broken or use separate data paths.
The way I see it there is only one other way that can make sense for all this. That would be to have a single user interface for all possible instances that controls all of them all the time but that is complex and not the way you have it set up. If you have another way that makes total sense other than per deck data please state that.
Adion wrote :
I'm also wondering when you would want to use the same plugin with different options for decks/master/audioOnlyVis.
Because you designed it that way and is the way you have it set up with multiple interfaces. All effects set the data per deck or master because that is also part of the internal design and VDJ user interface. The difference in what I do is I save this information per deck or master and most other effects do not. The other effects do something totally counter intuitive and not many know what they are doing in this area because it makes no sense to any rational thinking. I mentioned the 'don't do that list'. In my mind, I have also started the 'goofy list'.
Adion wrote :
As for the saving of settings, the way it currently works is that the settings are saved for the instance that is closed last. It is true that it is not intuitive for users to know which instance that is going to be. This should be improved so that the settings of the instance for which parameters have been changed last get saved.
That would only be a very minor improvement and this will still be on the 'goofy list'. That is because when the user sets the data, it will work as expected, but the next time it needs to load it may or may not. You will still be over writing what the user set in some cases and user will still not know why. I actually went thru several iterations on how this might work. It is not that I really wanted to save info per deck master, but it is the only thing that makes true deterministic sense the way you have it set up.
Early on looking at this a lot and listening to confusion about why this did not work as expected in the threads there was only one conclusion I could make and this is some of the detail for that.
When I first started with VDJ8, it was clear you had a different user interface for each deck or master. These interfaces change the data for it's instance while it is running. But depending on which way the wind is blowing, the data you set may not be actually be saved. It makes no sense to have different interfaces for each instance if it does not actually work which is the case now for most Atomix effects. An interface either controls all of it's instances with the same data or it has specific data for each instance. In the case of VDJ7, you had a single interface for each named effect and in order to get different interfaces you need to make copies of the effect with a new name which you can still do in 8. So a natural way to get different data sets. In comes VDJ8 with it's multiple interfaces allowing one for each instance and at the time initially deciding what to do about it. I think well it is simpler from a users perspective to have one interface that controls the same named plugin no matter what deck it is on. But then VDJ8 has provided for an interface for each deck or master. I think it is a natural thought to have separate data when you have separate interfaces. Now I did not make the decision based on just multiple interfaces. I am thinking well you don't have to keep renaming the plugin to get new data sets. Also looking at the native plugins they can't be copied so it must be the plan to have different data sets for each instance. So using the native camera effect, even if you set say a camera for one deck and a different camera on another deck it will work for the instance until next time you run VDJ it will no longer have the 2 cameras. Are you suggesting I should have followed this broken pattern? Multiple instances of the effect in a single DLL is really no different then having different named effects. The only issue with saving the data is knowing what deck or master it is on. I did not see it as a real choice. Either make it broken or use separate data paths.
The way I see it there is only one other way that can make sense for all this. That would be to have a single user interface for all possible instances that controls all of them all the time but that is complex and not the way you have it set up. If you have another way that makes total sense other than per deck data please state that.
Posted Mon 08 Jun 15 @ 11:22 am
Adion
Quote :
In the case of VDJ7, you had a single interface for each named effect and in order to get different interfaces you need to make copies of the effect with a new name which you can still do in 8.
VDJ7 worked pretty much the same as VDJ8. When you have an effect active on both decks at the same time, it are different instances for which you can set parameters independently.
When you close and re-open vdj, only one set of parameters has been saved, and this is the initial position for both decks at that point.
Posted Mon 08 Jun 15 @ 11:40 am
Don Moir
Adion wrote :
The idea of selecting an audioOnlyVis is to have something that works automatically.
You configure it once but then I don't think it would be useful to still have it selected it in an effect slot.
If you wanted to have full manual control all the time why would you select it as audioOnlyVis to begin with?
You configure it once but then I don't think it would be useful to still have it selected it in an effect slot.
If you wanted to have full manual control all the time why would you select it as audioOnlyVis to begin with?
No one is saying you need full manual control all the time and TM and TV work automatically remembering that data that was previously set by the user.
With TM and TV you can rename them to get different data or you can load layouts. You could have hundreds of named plugins or you can have hundreds of named layouts. Is user suppose to have hundreds of short named dlls or hundreds of named layouts? With named layouts it is much easier to define what the layout does. Take clipbank for example. It had 12 possible slots. User may have thousands of videos he would like to show. Say user has 2000 videos he would like to show. Some have many more and some have less. In the case of clipbank, he would need 2000 / 12 which is about 167 plugins to show this. I suppose that makes total sense to you :) With TM or TV you can just change the data by using meaningful names without having named plugins but you can also do that.
The way you are managing the user interface for audioOnlyVis is probably at the top of my 'goofy list'. decks and master have a distinction but audioOnlyVis do not. From the user interface point of view, users see only decks and master with effects listed for each. There is no clue about any of that being an audioOnlyVis from the user interface. All user sees for audioOnlyVis is things disappear from the user interface and probably don't know why. effects are removed from the interface and the interface can just disappear or be renamed. When user tries to deactivate an audioAudioVis it does not work and I have been asked about that many times. It isn't brain science to decide these things are just plain goofy.
An audioOnlyVis skin slot completely takes care of all the problems with this. It becomes just like a special kind deck and all problems solved. Your real problem from the get go is when you released you seem to have no real game plan on how audioOnlyVis should work and it has changed a couple times. Now you are stuck with trying to put this kind of thing in somewhere and it is not good the way I see it. Maybe you need to step back and take more of an objective look at it. I know it is easy to get so tied into details at times that it can be hard to see a broader picture.
I am not out to tear you down and I am trying to be constructive so that you will have a better product.
Posted Mon 08 Jun 15 @ 12:22 pm
Don Moir
Adion wrote :
VDJ7 worked pretty much the same as VDJ8. When you have an effect active on both decks at the same time, it are different instances for which you can set parameters independently.
When you close and re-open vdj, only one set of parameters has been saved, and this is the initial position for both decks at that point.
Quote :
In the case of VDJ7, you had a single interface for each named effect and in order to get different interfaces you need to make copies of the effect with a new name which you can still do in 8.
VDJ7 worked pretty much the same as VDJ8. When you have an effect active on both decks at the same time, it are different instances for which you can set parameters independently.
When you close and re-open vdj, only one set of parameters has been saved, and this is the initial position for both decks at that point.
With 7 it looks like you can have the same audio effect on different decks but don't see a way to have different video effects on different decks. Maybe there is with controller or different skins etc but did not pay much attention to that. With 8 it is a more in your face thing and hope you will make comments about the other mentioned things rather than just this.
Posted Mon 08 Jun 15 @ 12:29 pm
Don Moir
Adion wrote :
My guess is that most plugins are build for doing a specific thing, whereas your plugin is more monolithic and can be used for a wide variety of different purposes.
While this has no bearing at all the way that data is saved, it is very true that most plugins do not do much. In the case of video effects, all most plugins do is essentially draw something with not much in the way of a user interface. I am not saying that this approach is not good. It makes sense to do this kind of thing but I have no interest in that. Early on we knew that VDJ was no place to make any money from a business stand point. I have no interest is spending all my time doing something for no financial gain and most of the DJs charge for their time as well. The reason I did not just leave this place years ago, is because VDJ is a very good match for my past with multimedia and a very good place for future development. This is the only way I can make the time spent worth the investment. With that said, I have done everything possible to make them work as well they can within the VDJ environment and this has not always been easy. It is much easier to use the underlying tools where I have complete control over things and they tend to work better and in some cases, much better.
With VDJ, it is generally better to keep the plugins relatively dumb and with VDJ8 it is much easier to use the provided interface tools and let it more or less do the work of saving etc. even if it does not actually work well. That is to say, the saving does not work well, the provided user interface elements do not work well etc. Dials do not replace sliders or list boxes well, buttons that you can't really tell if they are pressed or not, text that you can't really read, are other problems but unrelated to what this thread is all about.
Posted Mon 08 Jun 15 @ 1:34 pm