d17e

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.

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).

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

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

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

> 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.

> #P user jit.pwindow 349 421 82 62 0 1 0 0 1 0;

> #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 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 newex 126 306 134 9109513 jit.gl.render test @automatic 0;

> #P fasten 6 0 8 0 160 264 307 264 307 491 330 491;

> #P fasten 12 0 8 0 360 342 307 342 307 491 330 491;

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

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;
>
>


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?

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?


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

> 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?

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.

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?
>


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

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...

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.

> 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...

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.

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
>
>
>


to end this thread i'd like to inform the list about the real cause of my

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...

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.

> > 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

> > 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

> > 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...

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...

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
> >
> >
> >
>
>


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