"automatic 0" and delays with send and receive to subpatches

Sep 22, 2006 at 7:37pm

"automatic 0" and delays with send and receive to subpatches

Hi list,

i’ve been working on a videomixer for quite a while now, and is working pretty fluent and stable (thanks to my hard work and offcourse the support i got overhere, thanks guys!). While i was working though, i kept most of my basal functionality inside one subpatch.
Now ,only for workability reasons, i’ve been dividing different functional parts of my patch into different subpatches. All ok it seemed, until i tested all of the videoplanes… it seems they are no longer drawn to. After some investigation i found out that it is the banging that gave me this issue (i’m using ‘automatic 0′ to control the order in which the planes are drawn).

In the main patch i have a main drawing metro wich uses a trigger to erase the context and several bangs to draw the different planes i’m using. i’ve been using the send and receive objects to distribute my bang since day one, but up until now these were all in the same patch. So, what i’m looking for is a way to ‘synchronously’ send my bangs into my subpatchers so that drawing can still occur like it should…

I pasted a patch below which demonstrates the problem to what it all comes down. If someone can help me out, this would be greatly appreciated cause i’m way too exhausted to think of something myself for now, and i’d like to finish this project pretty soon…

anyhoo, have a nice and thanks for the input.
D

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 355 313 39 9109513 delay 1;
#P user jit.pwindow 349 421 82 62 0 1 0 0 1 0;
#P message 353 357 26 9109513 read;
#P newex 325 379 55 9109513 jit.qt.movie;
#P newex 325 504 288 9109513 jit.gl.videoplane test @automatic 0 @scale 1. 1. 1. @position 0 0 0;
#P button 155 189 15 0;
#P user gswitch2 155 208 39 32 0 0;
#P newex 126 145 53 9109513 t b b erase;
#P message 354 104 47 9109513 floating 1;
#P newex 354 126 66 9109513 jit.window test;
#P toggle 126 96 13 0;
#P newex 126 121 50 9109513 qmetro 30;
#P newex 126 306 134 9109513 jit.gl.render test @automatic 0;
#P connect 2 0 1 0;
#P connect 4 0 3 0;
#P connect 1 0 5 0;
#P connect 5 0 0 0;
#P fasten 5 2 0 0 173 181 131 181;
#P fasten 5 1 6 1 152 187 189 187;
#P connect 7 0 6 0;
#P connect 10 0 9 0;
#P fasten 9 0 11 0 330 409 355 409;
#P connect 9 0 8 0;
#P fasten 6 1 12 0 189 256 360 256;
#P fasten 6 0 8 0 160 264 307 264 307 491 330 491;
#P fasten 6 0 9 0 160 264 330 264;
#P fasten 12 0 8 0 360 342 307 342 307 491 330 491;
#P fasten 12 0 9 0 360 342 330 342;
#P window clipboard copycount 13;

#27744
Sep 22, 2006 at 7:52pm

Putting that delay in there is what kills the videoplane. Why did you do that?

wes

On 9/22/06, david wrote:
>
> Hi list,
>
> i’ve been working on a videomixer for quite a while now, and is working pretty fluent and stable (thanks to my hard work and offcourse the support i got overhere, thanks guys!). While i was working though, i kept most of my basal functionality inside one subpatch.
> Now ,only for workability reasons, i’ve been dividing different functional parts of my patch into different subpatches. All ok it seemed, until i tested all of the videoplanes… it seems they are no longer drawn to. After some investigation i found out that it is the banging that gave me this issue (i’m using ‘automatic 0′ to control the order in which the planes are drawn).
>
> In the main patch i have a main drawing metro wich uses a trigger to erase the context and several bangs to draw the different planes i’m using. i’ve been using the send and receive objects to distribute my bang since day one, but up until now these were all in the same patch. So, what i’m looking for is a way to ‘synchronously’ send my bangs into my subpatchers so that drawing can still occur like it should…
>
> I pasted a patch below which demonstrates the problem to what it all comes down. If someone can help me out, this would be greatly appreciated cause i’m way too exhausted to think of something myself for now, and i’d like to finish this project pretty soon…
>
> anyhoo, have a nice and thanks for the input.
> D
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P newex 355 313 39 9109513 delay 1;
> #P user jit.pwindow 349 421 82 62 0 1 0 0 1 0;
> #P message 353 357 26 9109513 read;
> #P newex 325 379 55 9109513 jit.qt.movie;
> #P newex 325 504 288 9109513 jit.gl.videoplane test @automatic 0 @scale 1. 1. 1. @position 0 0 0;
> #P button 155 189 15 0;
> #P user gswitch2 155 208 39 32 0 0;
> #P newex 126 145 53 9109513 t b b erase;
> #P message 354 104 47 9109513 floating 1;
> #P newex 354 126 66 9109513 jit.window test;
> #P toggle 126 96 13 0;
> #P newex 126 121 50 9109513 qmetro 30;
> #P newex 126 306 134 9109513 jit.gl.render test @automatic 0;
> #P connect 2 0 1 0;
> #P connect 4 0 3 0;
> #P connect 1 0 5 0;
> #P connect 5 0 0 0;
> #P fasten 5 2 0 0 173 181 131 181;
> #P fasten 5 1 6 1 152 187 189 187;
> #P connect 7 0 6 0;
> #P connect 10 0 9 0;
> #P fasten 9 0 11 0 330 409 355 409;
> #P connect 9 0 8 0;
> #P fasten 6 1 12 0 189 256 360 256;
> #P fasten 6 0 8 0 160 264 307 264 307 491 330 491;
> #P fasten 6 0 9 0 160 264 330 264;
> #P fasten 12 0 8 0 360 342 307 342 307 491 330 491;
> #P fasten 12 0 9 0 360 342 330 342;
> #P window clipboard copycount 13;
>
>

#84289
Sep 22, 2006 at 8:06pm

Hi,

I know the delay is killing the videoplane, but i get the same effect in my mixing patch. i just put it there to demonstrate my problem.

The thing that happens in my patch goes as follows, the bangs in between the erase and the jit.gl.render bang are sent via send objects to the videoplanes i’m using, only they’re not drawing anymore, and after all test i ran i’m pretty sure it can only be caused by a delay that seems to occur which indeed kills my videoplane.
So i was wondering if can assure the order of my bangs, or in other words, how do i assure a synchronous depth first execution for the bangs sent through the send and receive objects.

am i clear enough? or am i still missing the point?

#84290
Sep 22, 2006 at 8:12pm

I use this setup all the time. It sounds like what you’re trying to
do. Can you post your actual patch and not a simulation? I’ve never
had any delay issues with send/receive.

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 59 197 53 196617 s vplane2;
#P newex 55 139 30 196617 t b b;
#P newex 105 170 53 196617 s vplane1;
#P newex 28 90 53 196617 t b b erase;
#P toggle 28 41 13 0;
#P newex 28 66 64 196617 qmetro 30;
#P newex 28 251 86 196617 jit.gl.render test;
#P connect 5 0 6 0;
#P connect 5 1 4 0;
#P connect 3 1 5 0;
#P fasten 3 2 0 0 75 126 33 126;
#P connect 3 0 0 0;
#P connect 2 0 1 0;
#P connect 1 0 3 0;
#P window clipboard copycount 7;

On 9/22/06, david wrote:
>
> Hi,
>
> I know the delay is killing the videoplane, but i get the same effect in my mixing patch. i just put it there to demonstrate my problem.
>
> The thing that happens in my patch goes as follows, the bangs in between the erase and the jit.gl.render bang are sent via send objects to the videoplanes i’m using, only they’re not drawing anymore, and after all test i ran i’m pretty sure it can only be caused by a delay that seems to occur which indeed kills my videoplane.
> So i was wondering if can assure the order of my bangs, or in other words, how do i assure a synchronous depth first execution for the bangs sent through the send and receive objects.
>
> am i clear enough? or am i still missing the point?
>

#84291
Sep 22, 2006 at 8:38pm

Hi Wes,

I sent you a personal email whith the details on my patch. Thanks for your time!

D

#84292
Sep 23, 2006 at 4:45pm

Hi Wes and others,

with a fresh head i started the day by checking out once again what i posted last night. I tested some more stuff and actually found and solved what was going wrong.

Well the thing is, i solved it and know where the problem is, but i still don’t understand how this problem can occur, so i’m afraid i’m still missing something. also if i cut out the basics for which is going wrong and i paste it in a new patch everything seems to work ok… so there must be a deeper explanation…

Now for the solving part; first off some explanation, like probably many of u i’m using a trigger object with an erase (last outlet) and several bangs. Now, fixing my broken videoplane was just a matter of repositioning the send object connected to the outlet of the trigger object, which on its turn was sending bangs to the broken plane.

bizarre right? or does this sound like a common issue? Anyhow, if someone can shed some light on the situation i would greatly appreciate it. My patch is up and running again but i don’t like the fact that something is happening somewhere which i cannot grasp…

thanks!
d

#84293
Sep 23, 2006 at 6:36pm

To me it sounds as if you have problems with the sequence of execution.
This might be caused by e.g. not sticking to proper right-to-left and
bottom-to-top order when output from one object is connected to to
several others, or it might be caused by one “send” object sending to
several “receive” objects. In the latter case it is unprecitable which
“receive” receives first, and moving one of the receives might be
sufficient to change the order, not because of “right-to-left” but
rather because the sequence of how the objects are created in the Max
patch represented as text file format might change.

Sorry if this is way to simple suggestions. You could try banging one
frame only using “trace enabled” to see if everything is progressing
from trigger onwards in the sequence you meant it to.

Best,
Trond

david wrote:
> Hi Wes and others,
>
> with a fresh head i started the day by checking out once again what i posted last night. I tested some more stuff and actually found and solved what was going wrong.
>
> Well the thing is, i solved it and know where the problem is, but i still don’t understand how this problem can occur, so i’m afraid i’m still missing something. also if i cut out the basics for which is going wrong and i paste it in a new patch everything seems to work ok… so there must be a deeper explanation…
>
> Now for the solving part; first off some explanation, like probably many of u i’m using a trigger object with an erase (last outlet) and several bangs. Now, fixing my broken videoplane was just a matter of repositioning the send object connected to the outlet of the trigger object, which on its turn was sending bangs to the broken plane.
>
> bizarre right? or does this sound like a common issue? Anyhow, if someone can shed some light on the situation i would greatly appreciate it. My patch is up and running again but i don’t like the fact that something is happening somewhere which i cannot grasp…
>
> thanks!
> d
>
>
>

#84294
Sep 25, 2006 at 11:45am

Hi,

to end this thread i’d like to inform the list about the real cause of my
problems.

Though Trond’s suggestions sounded indeed a bit ‘simple’ i started checking
them out. I respected the right-to-left and bottom-to-top order of execution
everywhere in my patches, but when i checked the send and receive objects i
noticed that i had used the same names for two send objects in two patches
that are connected via jit.net.send and jit.net.recv… probably occurred
because i split up my patch after i functionally finished it. When i changed
this issue everything worked exactly as it should…

I never realised that this could cause such a trouble but it does. So using
unique names for each send and receive pair is a definitely a must…

Thanks to all for the support!

On 9/23/06, Trond Lossius < lossius@bek.no> wrote:
>
> To me it sounds as if you have problems with the sequence of execution.
> This might be caused by e.g. not sticking to proper right-to-left and
> bottom-to-top order when output from one object is connected to to
> several others, or it might be caused by one “send” object sending to
> several “receive” objects. In the latter case it is unprecitable which
> “receive” receives first, and moving one of the receives might be
> sufficient to change the order, not because of “right-to-left” but
> rather because the sequence of how the objects are created in the Max
> patch represented as text file format might change.
>
> Sorry if this is way to simple suggestions. You could try banging one
> frame only using “trace enabled” to see if everything is progressing
> from trigger onwards in the sequence you meant it to.
>
> Best,
> Trond
>
>
>
> david wrote:
> > Hi Wes and others,
> >
> > with a fresh head i started the day by checking out once again what i
> posted last night. I tested some more stuff and actually found and solved
> what was going wrong.
> >
> > Well the thing is, i solved it and know where the problem is, but i
> still don’t understand how this problem can occur, so i’m afraid i’m still
> missing something. also if i cut out the basics for which is going wrong and
> i paste it in a new patch everything seems to work ok… so there must be a
> deeper explanation…
> >
> > Now for the solving part; first off some explanation, like probably many
> of u i’m using a trigger object with an erase (last outlet) and several
> bangs. Now, fixing my broken videoplane was just a matter of repositioning
> the send object connected to the outlet of the trigger object, which on its
> turn was sending bangs to the broken plane.
> >
> > bizarre right? or does this sound like a common issue? Anyhow, if
> someone can shed some light on the situation i would greatly appreciate it.
> My patch is up and running again but i don’t like the fact that something is
> happening somewhere which i cannot grasp…
> >
> > thanks!
> > d
> >
> >
> >
>
>

#84295

You must be logged in to reply to this topic.