VIDEOS! So I have 5 videos (videos 0 through 4), [jit.gl.videoplane], that need an initial ordering/time seperation then they can do their thing. So I tried a couple of ways to initialize these videos (and separate their executing actions).

methodZero: [metro 1000] feeding [counter 0 5]. [Counter] would feed every video and each video would [select] it's number (video0 would get banged first, video1 would be the 2nd time [counter] is banged from [metro], etc.

methodOne: [trigger 0 b 1] would feed [gate] (1, 0 is going to gate's left inlet and bang going to gate's right inlet) then [counter 0 5] would get the gated message of bang. That [counter] works the same as the above and feeds the other videos, each video selecting their int out from the starting counter's information. (Note: [trigger 0 b 1] would be called again but based on video0's actions which has the similar effect of a time gap but more accurate)

conclusion: What would happen though is [counter] would just keep counting until it maxes out and not effectively space out the starting actions of each video plane. I know in theory these should work and when the very bare minimum is setup in a patch, everything works so much more. It is as if the number of objects in this patch is causing some glitch in [counter] to count from 0 to 5 as quickly as possible and too fast for [select] to operate. (only the end points of [counter] are able to be detected by [select], there is only video4 as I wanted to make sure to stop [counter] and have all actions to be smooth.).

Questions: is Max supposed to operate with several object in the same patch? Or must there be inlet / outlets or outside calls that prevent critical mass from being reached if a user wants a significant task completed? It wasn't like my volume was that large that classes should be needed (although making classes would have saved some time :D, if they exist for Max).

If anyone wants to poke through my final (semibuggy) project and see what they can make of the exact error (which the project is several lines long and quite logic intensive) then I can comment it up some and post it for you. I dont think it is fair to chuck this dense mess to the forums and say tell me what is wrong.

ELSE/FEEDBACK: If there is a max number of objects (to smoothly run a patch) then what is that number? Why doesnt Max have some warning about this value of criticality? Or did I miss the 0th grade CS course that said any CS problem should not exceed _ _ as _ is true with the a given language? At least logically it seems there would not be a problem to just add away to one patch until you have all parts working.

methodZero: [metro 1000] feeding [counter 0 5]. [Counter] would feed every video and each video would [select] it's number (video0 would get banged first, video1 would be the 2nd time [counter] is banged from [metro], etc.  

methodOne: [trigger 0 b 1] would feed [gate] (1, 0 is going to gate's left inlet and bang going to gate's right inlet) then [counter 0 5] would get the gated message of bang.  That [counter] works the same as the above and feeds the other videos, each video selecting their int out from the starting counter's information. (Note: [trigger 0 b 1] would be called again but based on video0's actions which has the similar effect of a time gap but more accurate)

conclusion: What would happen though is [counter] would just keep counting until it maxes out and not effectively space out the starting actions of each video plane. I know in theory these should work and when the very bare minimum is setup in a patch, everything works so much more.  It is as if the number of objects in this patch is causing some glitch in [counter] to count from 0 to 5 as quickly as possible and too fast for [select] to operate. (only the end points of [counter] are able to be detected by [select], there is only video4 as I wanted to make sure to stop [counter] and have all actions to be smooth.).

Questions:  is Max supposed to operate with several object in the same patch? Or must there be inlet / outlets or outside calls that prevent critical mass from being reached if a user wants a significant task completed?  It wasn't like my volume was that large that classes should be needed (although making classes would have saved some time :D, if they exist for Max).

ELSE/FEEDBACK: If there is a max number of objects (to smoothly run a patch) then what is that number? Why doesnt Max have some warning about this value of criticality? Or did I miss the 0th grade CS course that said any CS problem should not exceed _ _ as _ is true with the a given language? At least logically it seems there would not be a problem to just add away to one patch until you have all parts working.


sound off 1 2 ...