This is a relatively minor bug but I hate to say 'minor' since the whole visualization implementation is a bug in my opinion. I assume the code is just as confused as the user interface is :)
I am using the VDJ8 2 deck default skin. build 2522
1) select something as the visualization. It does not matter what but I used slideshow.
2) place a video on deck 1 or activate a video effect on deck 1. Slideshow is now active on deck 2
3) bring up the user interface for slideshow on deck 2 and this is a must.
4) select a video effect different from slideshow on deck 2 and activate it. Does not matter what video effect but I used title.
Now you will see title is selected on deck 2 and activated. You will see the slideshow user interface is up on deck 2. You have some video or video effect active on deck 1. Click on title to deactivate it. The slideshow UI will go away and title will deactivate as it is supposed to but the skin is still showing it as activated as seen below. It gives the impression that nothing happened when you try to deactivate Title but it did work. Just the skin indicates it did not.
More later. Easy to get burned out on the crappy visualization implementation.
I am using the VDJ8 2 deck default skin. build 2522
1) select something as the visualization. It does not matter what but I used slideshow.
2) place a video on deck 1 or activate a video effect on deck 1. Slideshow is now active on deck 2
3) bring up the user interface for slideshow on deck 2 and this is a must.
4) select a video effect different from slideshow on deck 2 and activate it. Does not matter what video effect but I used title.
Now you will see title is selected on deck 2 and activated. You will see the slideshow user interface is up on deck 2. You have some video or video effect active on deck 1. Click on title to deactivate it. The slideshow UI will go away and title will deactivate as it is supposed to but the skin is still showing it as activated as seen below. It gives the impression that nothing happened when you try to deactivate Title but it did work. Just the skin indicates it did not.
More later. Easy to get burned out on the crappy visualization implementation.
Posté Sat 07 Nov 15 @ 6:05 pm
I will have a look.
But for the sake of clarity again we will not be changing the visualisation system any time soon.
But for the sake of clarity again we will not be changing the visualisation system any time soon.
Posté Sun 08 Nov 15 @ 12:39 am
I can't see how you could use the word clarity to explain anything away since this is about designed confusion. It is not about me but about your user base which is the real value. If you said it 1000 times I would ask you 1001 times because it has been designed with no reasonable thought. When you released 8, I guess you decided it was ok to waste many 1000's of man hours because you failed badly in the so called well tested release of 8.
quote from Atomix staff: "...But what Atomix can do is ensure that when V8 is ready it will stand out in the right ways, rather than being buggy, crashing and causing more issues than anyone wants."
quote from Atomix staff: "At the end of the day V7 is THE most solid piece of software Atomix have ever released. So the expectation from us "the consumer", is that V8 should be superior to this in terms of both features and stability."
quote from Atomix staff: "And a complete rewrite of 10 years of code (v7) will of course take time ;) but we're almost there, as stated many times already, with a sticky on top of forum we are now in the last stages of beta testing, ironing out last bugs and fixes."
I know this must be a low figure but with some management the community could develop something special :)
quote from Atomix staff: "...But what Atomix can do is ensure that when V8 is ready it will stand out in the right ways, rather than being buggy, crashing and causing more issues than anyone wants."
quote from Atomix staff: "At the end of the day V7 is THE most solid piece of software Atomix have ever released. So the expectation from us "the consumer", is that V8 should be superior to this in terms of both features and stability."
quote from Atomix staff: "And a complete rewrite of 10 years of code (v7) will of course take time ;) but we're almost there, as stated many times already, with a sticky on top of forum we are now in the last stages of beta testing, ironing out last bugs and fixes."
I know this must be a low figure but with some management the community could develop something special :)
Posté Sun 08 Nov 15 @ 2:51 am
I'm not going to argue historical quotes with you, that's just pointless. I'm also not going to stoop to the level of making cheap shots about other peoples code.
Is there room for improvement? Yes sure, I'm an advocate of it having it's own skin area for example. I think you over-estimate the size of the issue personally. Support would be inundated with requests about that if it was the case and it just isn't happening.
The vis system is actually extremely uncomplicated from a code perspective. Just because you don't like it, doesn't make it messy, confused or unworkable.
Thankyou for your bug report, it has been logged and I will investigate it this coming week.
Is there room for improvement? Yes sure, I'm an advocate of it having it's own skin area for example. I think you over-estimate the size of the issue personally. Support would be inundated with requests about that if it was the case and it just isn't happening.
The vis system is actually extremely uncomplicated from a code perspective. Just because you don't like it, doesn't make it messy, confused or unworkable.
Thankyou for your bug report, it has been logged and I will investigate it this coming week.
Posté Sun 08 Nov 15 @ 3:37 am
It is uncomplicated if you don't care about how it works or you don't do anything like most plugins but it does not make it right. Most don't even know what is going on so how could they complain? I have enough trouble trying to explain it :) This whole story goes deeper than you realize but that's ok if you don't have a clue or care. Have you tested your own stuff lately? The real problem I have is there seemed to be no design for it prior to release and so you patched something in. Was probably too late to do anything reasonable with the skins and I do know about pressure to ship. You had about 3 years I think to design it didn't you?
Also not about attacking anyone. I among 1000s of others had high expectations for 8. I was a fan of the group that developed 7 but you can only throw so much crap at someone. I am still a fan but not as much but still have good respect for some at Atomix. I am mostly about working and getting things done and not complaining, and would very much like to say 'great job'.
Ok I said I had some questions. You have added things that don't seem to know what a visualization is. This apparently comes directly from the design or lack of one.
For example:
effect_show_gui "audioonlyvisualisation"
effect_select "audioonlyvisualisation"
I don't believe any of these actually work unless the visualization is active. Correct? So why would you add them if there is just going to be more confusion? The funny thing is that for some reason it makes perfect sense to add something that makes no sense to something that makes no sense haha... Sitting here laughing about it. You see I smile a lot but you can't see that in my words sometimes. They seem cold to me but that is the nature of coding and trying to explain things. I suppose they might work as expected some day.
I think it should be real easy for you to tell a plugin that a visualization instance is being loaded. That is, you must already know. How could you not know lol. I can tell you how you might not know but then you think for some unknown reason that this thing is clean I guess. If you want to add anything about audioonlyvisualisation then add something that works for pete's sake. You must know, because you just have to, but GetInfo master always returns true during every method except OnDraw for a visualization. Must be being loaded and managed on the master? Not even OnStart works for get master. Only in OnDraw do you get correct behavior and why your attempt to add audioonlyvisualsation script in part fails but goes beyond that I am sure. If you want to add something that works, then add something that tells you in any method that this is a frekin visualization instance. This is not much to ask for. Like GetInfo ("get_deck 'audioonlyvisualisation' ? true : false",&query); which would be similar to master and better set you up for the long run. Scott mentioned this: "I have added to the next build a new script command 'is_audioonlyvisualisation'". Is this just one of the things that don't work unless activated or does it actually work in all cases? I don't believe it has been added yet but that would be good if it actually worked but I don't think it can. That is you don't know it is potentially a vis instance at the time of loading. Sometimes you do but sometimes you don't know.
Now if you have a plugin that uses the VDJ interface and not a custom one, the deck or master is changed on the fly as the vis moves around. This can only be known in OnDraw as I see it. This is automatic for a plugin that is using the native user interface system. It is not automatic for a plugin that is not using the native UI. Oh yeah, I can poll in the OnDraw call to find out but this leads to next question.
First and can't say it enough, the should be a real deterministic way to determine if an instance is actually an audio only vis in any method of the instance but may be impossible because of design . If I have to though I will poll for it in OnDraw which I guess matches the built in clumsiness. In OnDraw now GetInfo ('master') works. Now I can determine the actual deck but must also ask what is on the left deck and the right deck to make a correct detection that this is the real audio only vis.
To determine the actual deck for a vis for a non native UI plugin I must do this currently in OnDraw:
1) find out the actual deck or master it is on.
2) check what is on the left deck and right deck. You can use is_video to determine if video is on either deck. But is_video does not tell you if a video effect is active on left or right deck. Having an active video effect on some deck that is not the vis is same is having a video on that deck as far as audio only vis detection goes. This is only true though for a plugin that sets the VDJFLAG_VIDEO_VISUALISATION in OnGetPluginInfo. By the way impossible to change this behavior on the fly or any flag that can be set only in OnGetPlugInfo... Not so good either.
Laughable you say it is uncomplicated lol... But of course you made something that should be very easy both internal and from user's perspective into a complicated mess. What? You want me to sugar coat it or something lol...
Ok now what is the syntax for determining if also a video effect is active on a deck that has the VDJFLAG_VIDEO_VISUALISATION set? As is usual when I have to do something like this, it appears to be undocumented.
Also not about attacking anyone. I among 1000s of others had high expectations for 8. I was a fan of the group that developed 7 but you can only throw so much crap at someone. I am still a fan but not as much but still have good respect for some at Atomix. I am mostly about working and getting things done and not complaining, and would very much like to say 'great job'.
Ok I said I had some questions. You have added things that don't seem to know what a visualization is. This apparently comes directly from the design or lack of one.
For example:
effect_show_gui "audioonlyvisualisation"
effect_select "audioonlyvisualisation"
I don't believe any of these actually work unless the visualization is active. Correct? So why would you add them if there is just going to be more confusion? The funny thing is that for some reason it makes perfect sense to add something that makes no sense to something that makes no sense haha... Sitting here laughing about it. You see I smile a lot but you can't see that in my words sometimes. They seem cold to me but that is the nature of coding and trying to explain things. I suppose they might work as expected some day.
I think it should be real easy for you to tell a plugin that a visualization instance is being loaded. That is, you must already know. How could you not know lol. I can tell you how you might not know but then you think for some unknown reason that this thing is clean I guess. If you want to add anything about audioonlyvisualisation then add something that works for pete's sake. You must know, because you just have to, but GetInfo master always returns true during every method except OnDraw for a visualization. Must be being loaded and managed on the master? Not even OnStart works for get master. Only in OnDraw do you get correct behavior and why your attempt to add audioonlyvisualsation script in part fails but goes beyond that I am sure. If you want to add something that works, then add something that tells you in any method that this is a frekin visualization instance. This is not much to ask for. Like GetInfo ("get_deck 'audioonlyvisualisation' ? true : false",&query); which would be similar to master and better set you up for the long run. Scott mentioned this: "I have added to the next build a new script command 'is_audioonlyvisualisation'". Is this just one of the things that don't work unless activated or does it actually work in all cases? I don't believe it has been added yet but that would be good if it actually worked but I don't think it can. That is you don't know it is potentially a vis instance at the time of loading. Sometimes you do but sometimes you don't know.
Now if you have a plugin that uses the VDJ interface and not a custom one, the deck or master is changed on the fly as the vis moves around. This can only be known in OnDraw as I see it. This is automatic for a plugin that is using the native user interface system. It is not automatic for a plugin that is not using the native UI. Oh yeah, I can poll in the OnDraw call to find out but this leads to next question.
First and can't say it enough, the should be a real deterministic way to determine if an instance is actually an audio only vis in any method of the instance but may be impossible because of design . If I have to though I will poll for it in OnDraw which I guess matches the built in clumsiness. In OnDraw now GetInfo ('master') works. Now I can determine the actual deck but must also ask what is on the left deck and the right deck to make a correct detection that this is the real audio only vis.
To determine the actual deck for a vis for a non native UI plugin I must do this currently in OnDraw:
1) find out the actual deck or master it is on.
2) check what is on the left deck and right deck. You can use is_video to determine if video is on either deck. But is_video does not tell you if a video effect is active on left or right deck. Having an active video effect on some deck that is not the vis is same is having a video on that deck as far as audio only vis detection goes. This is only true though for a plugin that sets the VDJFLAG_VIDEO_VISUALISATION in OnGetPluginInfo. By the way impossible to change this behavior on the fly or any flag that can be set only in OnGetPlugInfo... Not so good either.
Laughable you say it is uncomplicated lol... But of course you made something that should be very easy both internal and from user's perspective into a complicated mess. What? You want me to sugar coat it or something lol...
Ok now what is the syntax for determining if also a video effect is active on a deck that has the VDJFLAG_VIDEO_VISUALISATION set? As is usual when I have to do something like this, it appears to be undocumented.
Posté Sun 08 Nov 15 @ 5:00 am
Your reported issue has been fixed.
effect_show_gui "audioonlyvisualisation" has also been changed to work when the effect is not active and we have discussed including this somewhere where a user can access it without having to add a custom button or whatever.
A command "is_audioonlyvisualisation" has been added that will tell you if the specified deck has the visualisation active on it. This should work at any point during a plugins life cycle.
I will also look at adding a command to allow a plugin to determine (at any point it decides to query) if the exact instance of the plugin doing the query is the active visualisation.
You are correct about the plugin flags not being changeable - this has always been the case and is not going to change however so you'll have to live with it.
It's worth noting that a plugin instance may not always be the visualisation at every point during it's life cycle - it may not be initially but may become the visualisation later.
effect_show_gui "audioonlyvisualisation" has also been changed to work when the effect is not active and we have discussed including this somewhere where a user can access it without having to add a custom button or whatever.
A command "is_audioonlyvisualisation" has been added that will tell you if the specified deck has the visualisation active on it. This should work at any point during a plugins life cycle.
I will also look at adding a command to allow a plugin to determine (at any point it decides to query) if the exact instance of the plugin doing the query is the active visualisation.
You are correct about the plugin flags not being changeable - this has always been the case and is not going to change however so you'll have to live with it.
It's worth noting that a plugin instance may not always be the visualisation at every point during it's life cycle - it may not be initially but may become the visualisation later.
Posté Sun 08 Nov 15 @ 2:35 pm
Thanks for looking into things. I will take a look at what you have changed when we get the next update.
Another issue may be when you become the audio only vis or when you stop being the audio only vis. That is user is changing the audio only vis in config. You could check but leads to some manual polling in various places. Could be useful to show in UI to better indicate what is going on.
When an effect is selected or you just bring up the UI and not active, currently you do not know if that will become the actual audio only vis. You do know if you are selected though as the audio only vis at load time though. It may be I will disallow some things depending on some of the details about this. Some things don't make any sense to a user because they do things without knowing and why would they. All they see is it is there and should make sense but like it does not make sense to do things that are just going be dumped anyway depending on how the audio only vis is moving around. If they never did these things I would not bring it up but it is just to easy for them to create difficulty with this and so they can become confused about it.
Another annoying issue is your persistence about calling OnStop and OnStart each time user decides to deactivate an audio only vis. User does this because it makes sense for him to do it because of the confused user interface, but it makes no sense to me that you call OnStop and OnStart each time user does it.
Another issue may be when you become the audio only vis or when you stop being the audio only vis. That is user is changing the audio only vis in config. You could check but leads to some manual polling in various places. Could be useful to show in UI to better indicate what is going on.
When an effect is selected or you just bring up the UI and not active, currently you do not know if that will become the actual audio only vis. You do know if you are selected though as the audio only vis at load time though. It may be I will disallow some things depending on some of the details about this. Some things don't make any sense to a user because they do things without knowing and why would they. All they see is it is there and should make sense but like it does not make sense to do things that are just going be dumped anyway depending on how the audio only vis is moving around. If they never did these things I would not bring it up but it is just to easy for them to create difficulty with this and so they can become confused about it.
Another annoying issue is your persistence about calling OnStop and OnStart each time user decides to deactivate an audio only vis. User does this because it makes sense for him to do it because of the confused user interface, but it makes no sense to me that you call OnStop and OnStart each time user does it.
Posté Sun 08 Nov 15 @ 4:39 pm
Just some more evidence for you how things can be confused. Using text effect as audio only vis. The text effect has a non native UI and below shows it is confused which is natural because the audio only vis implementation is poor. One is on the master and one is on deck 2. They are not both on the master as indicated in the caption bar.
Posté Mon 09 Nov 15 @ 3:47 pm
Maybe you are looking at things in more detail and that would be good. In the meantime I will still need some fallback position. You see in the image below that if I can detect the audio only vis, I can mark that in the user interface. Any other instances that the user may bring up are really no-ops since they are very likely to be dumped by the visualization moving around. This is why things can just disappear unexpectedly. The thing marked master below should be disabled and can do that in my own UI but becomes more of a headache when manipulated from the VDJ UI. It makes no sense to activate the non audio only vis instances because these will get stomped on by the real audio only vis.
So I do not know if it is possible externally to detect the presence of an active video effect on a deck that specifically has VDJFLAG_VIDEO_VISUALISATION flag set. I am not sure if this is a bug or not either. As it stands these things effect the detection of audio only vis. If I can query this now what is the syntax for it? If I can't query for this, then I will have a different fallback position.
For those who don't know, audio only visualizations don't really have a deck assignment. They are unique just like decks and master are unique. The problem is currently they are being shared with decks and or master which creates all the problems both internally and from the users perspective.
So I do not know if it is possible externally to detect the presence of an active video effect on a deck that specifically has VDJFLAG_VIDEO_VISUALISATION flag set. I am not sure if this is a bug or not either. As it stands these things effect the detection of audio only vis. If I can query this now what is the syntax for it? If I can't query for this, then I will have a different fallback position.
For those who don't know, audio only visualizations don't really have a deck assignment. They are unique just like decks and master are unique. The problem is currently they are being shared with decks and or master which creates all the problems both internally and from the users perspective.
Posté Tue 10 Nov 15 @ 5:17 pm
Might as well throw this into the mix of problems while we are at it.
Audio only visualizations become active when the video screen is up and there is no video on the left and right decks. If an audio only vis has been made active by the given rules, it remains active if the video screen has been hidden. All that happens in this case is OnDraw is not called. All the threads that the plugin may be using are still active and processing and doing their thing. That is because OnStop has not been called. You don't seem to have any problem calling OnStop and OnStart when not needed but you seem you have a problem calling OnStop when it is needed in this case. Not to big a deal but just more BS. If the video screen is up and there is video in both the left and right decks then it does become inactive. Kind of strange there is a difference here don't you think?
Audio only visualizations become active when the video screen is up and there is no video on the left and right decks. If an audio only vis has been made active by the given rules, it remains active if the video screen has been hidden. All that happens in this case is OnDraw is not called. All the threads that the plugin may be using are still active and processing and doing their thing. That is because OnStop has not been called. You don't seem to have any problem calling OnStop and OnStart when not needed but you seem you have a problem calling OnStop when it is needed in this case. Not to big a deal but just more BS. If the video screen is up and there is video in both the left and right decks then it does become inactive. Kind of strange there is a difference here don't you think?
Posté Tue 10 Nov 15 @ 7:28 pm
I pretty much have this working as best I can given the lunacy of it all. I can track the visualization instance pretty well when both active and not active. I disallow activation of non audio vis instances. An initial activation of a non audio only vis activates the real audio only vis if appropriate. An attempt to bring up the user interface for a non audio only vis brings up the interface for the real audio only vis. You could say this is a little bit unexpected behavior but it prevents you from doing things that can't possibly work so it is a trade off until you really fix this thing. My hours spent on audio only visualizations since first release of 8 both in trying to provide work arounds and trying to explain the craziness are huge. Not to mention the embarrassment when things don't work in my own stuff because of your failure to even have a game plan for all this on release.
One main thing is preventing me from putting this up for additional testing. I have asked twice if there is a way to detect the presence of a video effect on a deck that has the VDJFLAG_VIDEO_VISUALISATION set and I have received no answer so asking a third time. When you don't answer I assume it is another thing you did not think about and you should mark it is a bug if it cannot work. You should also let me know if it does not work. If you say you are adding things that work instead but don't always work I don't really need something that does not always work. I have something that always works but I need to be able to query for presence of a video effect that has the VDJFLAG_VIDEO_VISUALISATION set. Of course my detection of things may change in an on going way if you change things up or break them or when you really fix it.
Another thing is to at least be able to detect an audio only vis in OnStart. I can pretty much track without but in some cases it is useful to have in OnStart and not just OnDraw. Of course most useful to have it anywhere.
You have mentioned you have made changes but did not see any in last update. Please, have you made any changes and when will they be available ?
One main thing is preventing me from putting this up for additional testing. I have asked twice if there is a way to detect the presence of a video effect on a deck that has the VDJFLAG_VIDEO_VISUALISATION set and I have received no answer so asking a third time. When you don't answer I assume it is another thing you did not think about and you should mark it is a bug if it cannot work. You should also let me know if it does not work. If you say you are adding things that work instead but don't always work I don't really need something that does not always work. I have something that always works but I need to be able to query for presence of a video effect that has the VDJFLAG_VIDEO_VISUALISATION set. Of course my detection of things may change in an on going way if you change things up or break them or when you really fix it.
Another thing is to at least be able to detect an audio only vis in OnStart. I can pretty much track without but in some cases it is useful to have in OnStart and not just OnDraw. Of course most useful to have it anywhere.
You have mentioned you have made changes but did not see any in last update. Please, have you made any changes and when will they be available ?
Posté Fri 13 Nov 15 @ 6:49 pm
Don Moir wrote :
if there is a way to detect the presence of a video effect on a deck that has the VDJFLAG_VIDEO_VISUALISATION set
No there isn't a way. I might be more inclined to answer you if you wound your attitude back a little.
Don Moir wrote :
When you don't answer I assume it is another thing you did not think about and you should mark it is a bug if it cannot work.
I've already said ways will be added for you to detect if your deck is the visualisation instance or not, and that these methods will work in OnLoad, OnStart etc. You'll also be able to open the GUI for an inactive audioonlyvisualisation instance. So you won't need to worry about what is running on another deck.
We've also made some changes to the visualisation setup; it will be more likely to reuse an existing instance of the plugin if one is already running.
Don Moir wrote :
You have mentioned you have made changes but did not see any in last update. Please, have you made any changes and when will they be available ?
The last build was just a quick fix for netsearch. The changes will be in the next build.
Posté Fri 13 Nov 15 @ 7:17 pm
SBDJ wrote :
No there isn't a way. I might be more inclined to answer you if you wound your attitude back a little.
I would be inclined to be nice if your company took on the responsibility of it all like a real company should. But you have passed that responsibility on to your users and created much more work and aggravation for them than what should have been necessary. You start out above by saying in effect your company does not take responsibility for it words and then you say 'just because I don't like it'. My dog sits next to me while I work and since he understands as much as any person around me what I do, I asked him what he thought about all this. Sometimes when I ask him what he thinks he will give me a bark or two. When I asked this time he just gave me a blank stare. I said that is exactly right. That's what people are doing now because they don't have a clue what is going on :)
SBDJ wrote :
I've already said ways will be added for you to detect if your deck is the visualisation instance or not, and that these methods will work in OnLoad, OnStart etc. You'll also be able to open the GUI for an inactive audioonlyvisualisation instance. So you won't need to worry about what is running on another deck.
I assume it will still not work when not activated. I can detect that now but it needs to be able to detect presence of video effect with the vis flag set. I mentioned also I may wish to have a fall back position. It seems to me that if you have is_audioonlyvisualization that also needs to be able detect presence of video effect with vis flag set so why not surface this ability. You have to agree that this whole thing is very messy when it should not be. It could be you have something like is_video but in addition have is_videoOrVisualisation.
Also note that this has been going on since day one of the 8 release and now you want me to sugar coat everything. I feel like if I don't beat you over the head with it nothing will change. Since looking at this again the last couple weeks I have reported 2 more bugs with this. One severe and one minor. Also 2 more things that don't work. Now you wonder why some might be pissed. geeze
Posté Fri 13 Nov 15 @ 7:40 pm
Don Moir wrote :
I assume it will still not work when not activated
Well I did say it would work in OnLoad. I did also say that just because the engine says at one point it is or is not the visualisation don't assume that it's always the case throughout the lifetime of the plugin.
The problem isn't you reporting issues, that's fine. The problem is the way you seem to have to absolutely make multiple digs in every single post.
We also aren't going to change the way the whole visualisation engine works to suit you. We will of course fix bugs as they appear and make improvements as required.
Posté Fri 13 Nov 15 @ 8:26 pm
I assume it will work in OnLoad when the vis is actually being loaded. I have to assume right now though, if it is loaded implicitly by being selected it will not work but I hope I am wrong about that.
Maybe you missed the point about the dog story above. I mentioned that people, meaning your end users, just end up staring since they do not know what is going on. It does not matter about me and all I ask for is things that work so I can do a better job.
Maybe you missed the point about the dog story above. I mentioned that people, meaning your end users, just end up staring since they do not know what is going on. It does not matter about me and all I ask for is things that work so I can do a better job.
Posté Fri 13 Nov 15 @ 10:31 pm
Ok, so I've just double checked and it won't work when being loaded as the plugin is only assigned if it successfully loads.
Some of the changes may actually not be in the next build unfortunately.
Some of the changes may actually not be in the next build unfortunately.
Posté Sat 14 Nov 15 @ 9:52 am
With the way you have things working in build 2523, I am able to successfully predict what will become or what is the real audio only visualization. It does not depend on activation or when loaded etc. The problems with it right now are:
1) There is no way to determine if a visualization is active on a deck. This effects the prediction. Works fine if I just look for video.
2) This is tied to an implementation which is subject to change.
I would think if I can predict it from external point of view you should know it for sure internally or it's design should be that it is 100% predictable. As far as I can tell I am 100% successful with the prediction given the constraints with it. So I am on hold waiting to see what will come next and I am trying to get new updates out.
I am very calm today but I want to mention that reporting bugs for you is not some kind of privilege for me. It can take a lot of time to report a bug. The point about me mentioning that I recently reported more problems, was that, I am STILL reporting problems with audio only vis. As I see it, since the design is bad, this leads to bugs in all areas. I see this as constructive criticism and if you can't take criticism with software, then you should find another job.
1) There is no way to determine if a visualization is active on a deck. This effects the prediction. Works fine if I just look for video.
2) This is tied to an implementation which is subject to change.
I would think if I can predict it from external point of view you should know it for sure internally or it's design should be that it is 100% predictable. As far as I can tell I am 100% successful with the prediction given the constraints with it. So I am on hold waiting to see what will come next and I am trying to get new updates out.
I am very calm today but I want to mention that reporting bugs for you is not some kind of privilege for me. It can take a lot of time to report a bug. The point about me mentioning that I recently reported more problems, was that, I am STILL reporting problems with audio only vis. As I see it, since the design is bad, this leads to bugs in all areas. I see this as constructive criticism and if you can't take criticism with software, then you should find another job.
Posté Sat 14 Nov 15 @ 9:54 pm
Looks like I can do this without knowing if video or visualization is on a deck but still will be sensitive to any changes that might be made.
The detection for me depends on knowing that when the real vis is loaded it will indicate it is on master in OnLoad. At this point it does not matter if it is active or not. Later as the vis moves around and I get another load OnLoad for different instance on master I can also detect that. In build 2523 and prior, visualizations can be dumped etc... and knowing how the handling is done means I can predict the visualization. If you change this behavior of course I will need to change the detection.
Knowing this means I can force the TM user interface to not just disappear, and prevent things that make no sense... Like activating an audio only vis on a deck that will just be removed as the vis moves around. I can force it to have just one user interface that stays stable instead of having user interfaces disappear.
The detection for me depends on knowing that when the real vis is loaded it will indicate it is on master in OnLoad. At this point it does not matter if it is active or not. Later as the vis moves around and I get another load OnLoad for different instance on master I can also detect that. In build 2523 and prior, visualizations can be dumped etc... and knowing how the handling is done means I can predict the visualization. If you change this behavior of course I will need to change the detection.
Knowing this means I can force the TM user interface to not just disappear, and prevent things that make no sense... Like activating an audio only vis on a deck that will just be removed as the vis moves around. I can force it to have just one user interface that stays stable instead of having user interfaces disappear.
Posté Sun 15 Nov 15 @ 6:23 am
While I can kind of manage all this with build 2523 and prior, another issue is becoming the visualization or being removed as the visualization. Right now I have to continuously poll for this via a timer. The only time I do not have to poll is when TM is active as a visualization. It has been noted that the way you have things setup for visualizations is error prone. It also leads to user confusion. So don't change visualizations on my account, but change it for you, your users, and your own credibility. As I see it, this can only be done by giving the audio only visualizations a home slot on the skins. I can only imagine what kind of time has been spent on trying to implement something that can never really work rather then fixing it for real. This would mean you would have to change skins but then everything should be clean on all ends.
Posté Tue 17 Nov 15 @ 3:55 pm