Mattijs

I output a bang that triggers a message back into js, which is catched by anything(). The inlet property then reports an incorrect inlet number. Have a look at the example below.

    post("input in inlet " + inlet + ": " + messagename);

function anything()
{
	post("input in inlet " + inlet + ": " + messagename);
}

bugreport-inlet-property-gives-incorrect-inlet-number

On Jan 1, 2007, at 1:31 PM, Mattijs Kneppers wrote:

> I output a bang that triggers a message back into js, which is 

> catched by anything(). The inlet property then reports an incorrect 

> inlet number. Have a look at the example below.

In general, this type of recursion is not supported for objects which 

use proxy inlets, as does js, all MSP objects and many more. You'll 

need to use some kind of event deferral or something to separate the 

recursion into multiple events sequenced over time.

To re-phrase, the reported inlet number cannot be relied upon to be 

accurate in the instance of feedback loops. Hope this helps.

> I output a bang that triggers a message back into js, which is  
> catched by anything(). The inlet property then reports an incorrect  
> inlet number. Have a look at the example below.

In general, this type of recursion is not supported for objects which  
use proxy inlets, as does js, all MSP objects and many more. You'll  
need to use some kind of event deferral or something to separate the  
recursion into multiple events sequenced over time.

To re-phrase, the reported inlet number cannot be relied upon to be  
accurate in the instance of feedback loops. Hope this helps.

Quote: jkc wrote on Tue, 02 January 2007 22:57

----------------------------------------------------

> On Jan 1, 2007, at 1:31 PM, Mattijs Kneppers wrote:

> > I output a bang that triggers a message back into js, which is 

> > catched by anything(). The inlet property then reports an incorrect 

> > inlet number. Have a look at the example below.

> In general, this type of recursion is not supported for objects which 

> use proxy inlets, as does js, all MSP objects and many more. You'll 

> need to use some kind of event deferral or something to separate the 

> recursion into multiple events sequenced over time.

> To re-phrase, the reported inlet number cannot be relied upon to be 

> accurate in the instance of feedback loops. Hope this helps.

Thanks for your reply. It's a pity, I would have loved to use a feedback loop this way. I guess that could be made a feature request since I believe this is not a conceptual but a technical limitation (am I right?).

Quote: jkc wrote on Tue, 02 January 2007 22:57
----------------------------------------------------
>
> On Jan 1, 2007, at 1:31 PM, Mattijs Kneppers wrote:
>
> > I output a bang that triggers a message back into js, which is  
> > catched by anything(). The inlet property then reports an incorrect  
> > inlet number. Have a look at the example below.
>
> In general, this type of recursion is not supported for objects which  
> use proxy inlets, as does js, all MSP objects and many more. You'll  
> need to use some kind of event deferral or something to separate the  
> recursion into multiple events sequenced over time.
>
> To re-phrase, the reported inlet number cannot be relied upon to be  
> accurate in the instance of feedback loops. Hope this helps.
>
> -Joshua

> Thanks for your reply. It's a pity, I would have loved to use a feedback

> loop this way. I guess that could be made a feature request since I believe

> this is not a conceptual but a technical limitation (am I right?).

Not sure how you would like to use that strategy, but if you can't use

[defer(low)] inside the feedback loop, I doubt that what you're trying to do

is the (only) way to go. If you give us an example, maybe someone can give

On 1/5/07, Mattijs Kneppers  wrote:
>
>
>
> Thanks for your reply. It's a pity, I would have loved to use a feedback
> loop this way. I guess that could be made a feature request since I believe
> this is not a conceptual but a technical limitation (am I right?).
>
>
> Hi Mattijs,

Not sure how you would like to use that strategy, but if you can't use
[defer(low)] inside the feedback loop, I doubt that what you're trying to do
is the (only) way to go. If you give us an example, maybe someone can give
you a different solution.

Quote: thijskoerselman@gmail wrote on Fri, 05 January 2007 11:13

> Not sure how you would like to use that strategy, but if you can't use

> [defer(low)] inside the feedback loop, I doubt that what you're trying to do

> is the (only) way to go. If you give us an example, maybe someone can give

I'd love to show you what I'm working on. I attached the files. But although I tried to make nice help files to guide you through the idea I expect that it is quite complex (or complicated) to find out 1) how I made this work and 2) why I'm trying to do it.

Still, if you want to try, you're more than welcome. If you find an alternative I'll definitly buy you a beer.

In the attachment, to have a quick view of the idea, open 1.pat. For more explanation, open the .help files separately.

Btw, the layout of the patchers is done on pc, didn't test on mac. I hope it doesn't look very bad on mac.

Quote: thijskoerselman@gmail wrote on Fri, 05 January 2007 11:13
----------------------------------------------------
> > Hi Mattijs,
>
> Not sure how you would like to use that strategy, but if you can't use
> [defer(low)] inside the feedback loop, I doubt that what you're trying to do
> is the (only) way to go. If you give us an example, maybe someone can give
> you a different solution.
>
> cheers, -thijs

I'd love to show you what I'm working on. I attached the files. But although I tried to make nice help files to guide you through the idea I expect that it is quite complex (or complicated) to find out 1) how I made this work and 2) why I'm trying to do it. 

Btw, the layout of the patchers is done on pc, didn't test on mac. I hope it doesn't look very bad on mac.


On Jan 6, 2007, at 12:35 PM, Mattijs Kneppers wrote:

> Still, if you want to try, you're more than welcome. If you find an 

> alternative I'll definitly buy you a beer.

Well, now that there's an offer of alcohol involved, I'm a tad more 

I think that the following strategy works the way you wanted for your 

initial example--i.e. copy the messagename and inlet properties to a 

local variable. What happens internal to js is that messagename and 

inlet are global to the script, set and overwritten with each message 

call. Let me know if this doesn't solve your problem.

-------------------------------------------

    var mything = new String(messagename);

    if (mything == "first")    outlet(0, "next");

    post("messagename " + mything + ", inlet " + myinlet);

>
> Still, if you want to try, you're more than welcome. If you find an  
> alternative I'll definitly buy you a beer.

Well, now that there's an offer of alcohol involved, I'm a tad more  
motivated to think about the problem ;)

I think that the following strategy works the way you wanted for your  
initial example--i.e. copy the messagename and inlet properties to a  
local variable. What happens internal to js is that messagename and  
inlet are global to the script, set and overwritten with each message  
call. Let me know if this doesn't solve your problem.

test.js
-------------------------------------------

function anything()
{
	var mything = new String(messagename);
	var myinlet = inlet;

	if (mything == "first")	outlet(0, "next");
	post("messagename " + mything + ", inlet " + myinlet);
	post();
}

Quote: jkc wrote on Sat, 06 January 2007 22:01

> Well, now that there's an offer of alcohol involved, I'm a tad more 

> motivated to think about the problem ;)

> I think that the following strategy works the way you wanted for your 

> initial example--i.e. copy the messagename and inlet properties to a 

> local variable. What happens internal to js is that messagename and 

> inlet are global to the script, set and overwritten with each message 

> call. Let me know if this doesn't solve your problem.

The thread you're referring to is about a different issue than this thread (although I agree they look similar): 

https://cycling74.com/forums/index.php?t=msg&th=23675&start=0&rid=3579&S=a181cd3c624d8aaaff66f98640ed2749

I posted my reply there and I can say I'll happily buy you a beer the next time you're in amsterdam or I'm in san fransisco! :)

I also tried your solution for the issue discussed in this thread and I am afraid it doesn't work here. The beer for this one is still open ;)

Btw Joshua, I can imagine you or someone else at cycling could find the zip file I attached in my previous post interesting to give a few moments of attention. It is an attempt to add a core concept to max that doesn't exist yet. Or if you don't have time to check it now, I will post it as a feature request later (or email to support).

Quote: jkc wrote on Sat, 06 January 2007 22:01
----------------------------------------------------
> Well, now that there's an offer of alcohol involved, I'm a tad more  
> motivated to think about the problem ;)
>
> I think that the following strategy works the way you wanted for your  
> initial example--i.e. copy the messagename and inlet properties to a  
> local variable. What happens internal to js is that messagename and  
> inlet are global to the script, set and overwritten with each message  
> call. Let me know if this doesn't solve your problem.
>

The thread you're referring to is about a different issue than this thread (although I agree they look similar): https://cycling74.com/forums/index.php?t=msg&th=23675&start=0&rid=3579&S=a181cd3c624d8aaaff66f98640ed2749 

Btw Joshua, I can imagine you or someone else at cycling could find the zip file I attached in my previous post interesting to give a few moments of attention. It is an attempt to add a core concept to max that doesn't exist yet. Or if you don't have time to check it now, I will post it as a feature request later (or email to support).


On Jan 6, 2007, at 1:53 PM, Mattijs Kneppers wrote:

> The thread you're referring to is about a different issue than this 

> thread (although I agree they look similar): 

> t=msg&th=23675&start=0&rid=3579&S=a181cd3c624d8aaaff66f98640ed2749

> I posted my reply there and I can say I'll happily buy you a beer 

> the next time you're in amsterdam or I'm in san fransisco! :)

> I also tried your solution for the issue discussed in this thread 

> and I am afraid it doesn't work here. The beer for this one is 

Ah, yes, sorry for confusing the two similar threads, since they are 

similar problems and I didn't have the energy to figure out what that 

"pattr no matter how deep" example patch. .

This specific problem is with the leftmost inlet and proxies. This 

issue exists for all Max objects. To better clarify the issue is that 

the leftmost inlet is not a proxy inlet, and it doesn't specifically 

set the inlet number when receiving a message. All other inlets are 

proxy inlets and do in fact record the inlet number and then reset 

the inlet number to zero when done processing. Since this recursion 

is happening mid-processing, the inlet number is not reset to zero.

I can't think of a way to avoid this without some fairly serious 

infrastructure change to Max, or one of the following workarounds 

(which, while a bit ugly, should allow you to accomplish what you 

1. Put your js file inside a sub patcher which prepends a message for 

each inlet where you can accurately determine which inlet is called 

based on the method name. Something like:

2. Declare 3 inlets and use the middle and rightmost inlet. Since 

these two are both proxies, the correct inlet will be set upon 

function entry, even with this sort of recursion (but after any such 

recursive outlet call the global inlet value cannot be relied upon 

and you'll need to use local variables to cach on function entry like 

> The thread you're referring to is about a different issue than this  
> thread (although I agree they look similar): http:// 
> www.cycling74.com/forums/index.php? 
> t=msg&th=23675&start=0&rid=3579&S=a181cd3c624d8aaaff66f98640ed2749
>
> I posted my reply there and I can say I'll happily buy you a beer  
> the next time you're in amsterdam or I'm in san fransisco! :)
>
> I also tried your solution for the issue discussed in this thread  
> and I am afraid it doesn't work here. The beer for this one is  
> still open ;)

Ah, yes, sorry for confusing the two similar threads, since they are  
similar problems and I didn't have the energy to figure out what that  
"pattr no matter how deep" example patch. .

This specific problem is with the leftmost inlet and proxies. This  
issue exists for all Max objects. To better clarify the issue is that  
the leftmost inlet is not a proxy inlet, and it doesn't specifically  
set the inlet number when receiving a message. All other inlets are  
proxy inlets and do in fact record the inlet number and then reset  
the inlet number to zero when done processing. Since this recursion  
is happening mid-processing, the inlet number is not reset to zero.

I can't think of a way to avoid this without some fairly serious  
infrastructure change to Max, or one of the following workarounds  
(which, while a bit ugly, should allow you to accomplish what you  
want in the meantime):

1. Put your js file inside a sub patcher which prepends a message for  
each inlet where you can accurately determine which inlet is called  
based on the method name. Something like:

function inletleft()
{
	myowninlet = 0;
	//your logic goes here
}

function inletright()
{
	myowninlet = 1;
	//your logic goes here
}

2. Declare 3 inlets and use the middle and rightmost inlet. Since  
these two are both proxies, the correct inlet will be set upon  
function entry, even with this sort of recursion (but after any such  
recursive outlet call the global inlet value cannot be relied upon  
and you'll need to use local variables to cach on function entry like  
my solution for the other thread)

> I'd love to show you what I'm working on. I attached the files. But

> although I tried to make nice help files to guide you through the idea I

> expect that it is quite complex (or complicated) to find out 1) how I made

> this work and 2) why I'm trying to do it.

Yes it looks a little complicated, but for the most part I get what you're

doing. My first impression is that you use a lot of objects/code for (what

it seems is) sharing ,addressing and initializing variables in some kind of

global scope. It looks like you put a lot of thought in it, and since there

is no way for me to know how you use it exactly I can't really judge on

Still, if you want to try, you're more than welcome. If you find an

Is the beer offer still open after Joshua's reply? I just recovered from a

major hang-over but I'll give it a shot;-)

Did you have a look at Jeremy's pattrmarker? You can define a global name

within the pattr system, and use [pattr] in combination with "bindto" to

bind to a value anywhere in your patch without knowing where it is exactly.

(I just ran into an issue for which I will post a different tread). Of

course this doesn't instantly replace the layer and voice things you have

going on in your code, but it might be an eyeopener if you haven't looked at

That's as far as I go in my attempt to get a free beer.

btw: I didn't find where you wanted to apply the js recursion.

On 1/6/07, Mattijs Kneppers  wrote:
>
>
> I'd love to show you what I'm working on. I attached the files. But
> although I tried to make nice help files to guide you through the idea I
> expect that it is quite complex (or complicated) to find out 1) how I made
> this work and 2) why I'm trying to do it.

Yes it looks a little complicated, but for the most part I get what you're
doing. My first impression is that you use a lot of objects/code for (what
it seems is)  sharing ,addressing and initializing variables in some kind of
global scope. It looks like you put a lot of thought in it, and since there
is no way for me to know how you use it exactly I can't really judge on
that.

Still, if you want to try, you're more than welcome. If you find an
> alternative I'll definitly buy you a beer.

Is the beer offer still open after Joshua's reply? I just recovered from a
major hang-over but I'll give it a shot;-)

Did you have a look at Jeremy's pattrmarker? You can define a global name
within the pattr system, and use [pattr] in combination with "bindto" to
bind to a value anywhere in your patch without knowing where it is exactly.
(I just ran into an issue for which I will post a different tread). Of
course this doesn't instantly replace the layer and voice things you have
going on in your code, but it might be an eyeopener if you haven't looked at
it yet.

Thanks for your replies. Yeah, I checked all possibilities of the pattr family (hence 'try 15' ;). The pattrmarker defines a global address while what I need is a semi-local variable (an ordinary variable in other programming languages, one that has a scope).

Roughly, this script searches up in the patcher hierarchy to bind to the first matching pattr. That's what the recursion is currently used for. The whole thing is already fully functional but with a workaround for the issue discussed in this thread (check the TS.var.help file ;).

Btw, I was cheating. I normally buy ppl free beers without them having to return something. There's a nice party in Utrecht 19 jan in Tivoli (Speedy J does a 3 hours acid set). If you're around, let me know ;)

Quote: thijskoerselman@gmail wrote on Mon, 08 January 2007 01:51

> > I'd love to show you what I'm working on. I attached the files. But

> > although I tried to make nice help files to guide you through the idea I

> > expect that it is quite complex (or complicated) to find out 1) how I made

> > this work and 2) why I'm trying to do it.

> Yes it looks a little complicated, but for the most part I get what you're

> doing. My first impression is that you use a lot of objects/code for (what

> it seems is) sharing ,addressing and initializing variables in some kind of

> global scope. It looks like you put a lot of thought in it, and since there

> is no way for me to know how you use it exactly I can't really judge on

> Still, if you want to try, you're more than welcome. If you find an

> > alternative I'll definitly buy you a beer.

> Is the beer offer still open after Joshua's reply? I just recovered from a

> major hang-over but I'll give it a shot;-)

> Did you have a look at Jeremy's pattrmarker? You can define a global name

> within the pattr system, and use [pattr] in combination with "bindto" to

> bind to a value anywhere in your patch without knowing where it is exactly.

> (I just ran into an issue for which I will post a different tread). Of

> course this doesn't instantly replace the layer and voice things you have

> going on in your code, but it might be an eyeopener if you haven't looked at

> That's as far as I go in my attempt to get a free beer.

> btw: I didn't find where you wanted to apply the js recursion.

Thanks for your replies. Yeah, I checked all possibilities of the pattr family (hence 'try 15' ;). The pattrmarker defines a global address while what I need is a semi-local variable (an ordinary variable in other programming languages, one that has a scope). 

Quote: thijskoerselman@gmail wrote on Mon, 08 January 2007 01:51
----------------------------------------------------
> On 1/6/07, Mattijs Kneppers  wrote:
> >
> >
> > I'd love to show you what I'm working on. I attached the files. But
> > although I tried to make nice help files to guide you through the idea I
> > expect that it is quite complex (or complicated) to find out 1) how I made
> > this work and 2) why I'm trying to do it.
>
>
>
> Yes it looks a little complicated, but for the most part I get what you're
> doing. My first impression is that you use a lot of objects/code for (what
> it seems is)  sharing ,addressing and initializing variables in some kind of
> global scope. It looks like you put a lot of thought in it, and since there
> is no way for me to know how you use it exactly I can't really judge on
> that.
>
> Still, if you want to try, you're more than welcome. If you find an
> > alternative I'll definitly buy you a beer.
>
>
> Is the beer offer still open after Joshua's reply? I just recovered from a
> major hang-over but I'll give it a shot;-)
>
>
> > Let me know what you think ;)
>
>
> Did you have a look at Jeremy's pattrmarker? You can define a global name
> within the pattr system, and use [pattr] in combination with "bindto" to
> bind to a value anywhere in your patch without knowing where it is exactly.
> (I just ran into an issue for which I will post a different tread). Of
> course this doesn't instantly replace the layer and voice things you have
> going on in your code, but it might be an eyeopener if you haven't looked at
> it yet.
>
> That's as far as I go in my attempt to get a free beer.
>
> hth.
> cheers -thijs
>
>
> btw: I didn't find where you wanted to apply the js recursion.
>
>
>
----------------------------------------------------


Quote: jkc wrote on Sun, 07 January 2007 00:12

> Ah, yes, sorry for confusing the two similar threads, since they are 

> similar problems and I didn't have the energy to figure out what that 

> "pattr no matter how deep" example patch. .

> This specific problem is with the leftmost inlet and proxies. This 

> issue exists for all Max objects. To better clarify the issue is that 

> the leftmost inlet is not a proxy inlet, and it doesn't specifically 

> set the inlet number when receiving a message. All other inlets are 

> proxy inlets and do in fact record the inlet number and then reset 

> the inlet number to zero when done processing. Since this recursion 

> is happening mid-processing, the inlet number is not reset to zero.

That's interesting information. I'd love to hear where I could find out more about these issues. The max sdk?

> I can't think of a way to avoid this without some fairly serious 

> infrastructure change to Max, or one of the following workarounds 

> (which, while a bit ugly, should allow you to accomplish what you 

> 1. Put your js file inside a sub patcher which prepends a message for 

> each inlet where you can accurately determine which inlet is called 

> based on the method name. Something like:

That's right. I hoped to avoid the 2 extra [prepend set]s because this object is going to be used a lot. I'll stick to the second option then :)

> 2. Declare 3 inlets and use the middle and rightmost inlet. Since 

> these two are both proxies, the correct inlet will be set upon 

> function entry, even with this sort of recursion (but after any such 

> recursive outlet call the global inlet value cannot be relied upon 

> and you'll need to use local variables to cach on function entry like 

Cool, I didn't know about proxy inlets. I tested it and it works!

Quote: jkc wrote on Sun, 07 January 2007 00:12
----------------------------------------------------
> Ah, yes, sorry for confusing the two similar threads, since they are  
> similar problems and I didn't have the energy to figure out what that  
> "pattr no matter how deep" example patch. .

bugreport: inlet property gives incorrect inlet number