Emerson

This subject is likely to be explained somewhere in the forum, but although I searched a lot, I guess I couldn't choose the right keywords, so I'll be glad if you could help.

When I "encapsulate" some portion of an audio patch (in order to be able to use [mute~ ] on it, as it is declared to work on subpatches), the inlet object is connected not with a signal but a message cord. Is this normal? Does it have the possibility to malfunction? I'm trying to avoid a send~ / receive~ pair, since it is said to be applied with a delay.

Hello,
This subject is likely to be explained somewhere in the forum, but although I searched a lot, I guess I couldn't choose the right keywords, so I'll be glad if you could help.

generic-inlet-for-signals

There was a thread a little while ago in which EJ let us know that send~/receive~ only introduce a vector length delay when used in a feedback loop, so there is no downside to using them at all.

However, I've noticed this message cord for signal thing as well and never had any issues with it. I really don't think it's anything to worry about, it's just a visual "bug". As long as the receiving inlet can take a signal it will work perfectly.

There's a way of sending signals through a message cord that's pretty useful for abstractions. Use this after an inlet and you can have signals share the inlet with ints, floats, messages just like regular max objects. There doesn't seem to be any delay when doing this either.

However, I've noticed this message cord for signal thing as well and never had any issues with it.  I really don't think it's anything to worry about, it's just a visual "bug".  As long as the receiving inlet can take a signal it will work perfectly.

There's a way of sending signals through a message cord that's pretty useful for abstractions.  Use this after an inlet and you can have signals share the inlet with ints, floats, messages just like regular max objects.  There doesn't seem to be any delay when doing this either.


This is a guessing, but I think with encapsulating a part of the patch is rebuilt. In the proces, the inlet object inside the sub patch is created before the connection to the inlet of the sub patch is made. This has to do with the order with which max builds a patch out of a set of instructions. The inlet object is generic, so max won't know at instantiation time if the inlet is handing yes or not a signal, and therefor the patch chord leaving the inlet object will default to a non signal patch chord. As soon as you grab the connection (at the inlet of tapin~), it will immediately become a signal chord, as max is aware of the fact that a signal is connected to the inlet object. Does this make sense?

well it is simply that max cannot know what is coming in.

only when a signal had been connected to it before from outside, you will get a signal

only when a signal had been connected to it before from outside, you will get a signal
style patch cord inside.

Thanks for the comments. Actually I'm not willing to attempt many guesses about the inner workings without having seen the source code, but

I just wanted to know if it would run OK despite showing a msg cord, since I can only have access to the consequences.

Well, my example does not conform to your explanation, because a signal had been connected before.

The order of my editing process was as follows: I connected the adc to a tapping pair, and connected the output to dac.

Then I selected the objects between, and clicked "encapsulate" from the edit menu. At this point it was obvious that the inlet to the patcher object would receive a signal.

Even if one were to design inside a patcher object "after" creating it, Max "could" know what type of cord to use, as the "outlet of that inlet" would be connected to a certain object inside the "p". So, I feel closer to Mr Lloyd's assumption that it's a visual bug. Again, I was just waiting a confirmation from the developers that it would work OK anyway.

Thanks for the comments. Actually I'm not willing to attempt many guesses about the inner workings without having seen the source code, but
I just wanted to know if it would run OK despite showing a msg cord, since I can only have access to the consequences.

Well, my example does not conform to your explanation, because a signal had been connected before.
The order of my editing process was as follows: I connected the adc to a tapping pair, and connected the output to dac.
Then I selected the objects between, and clicked "encapsulate" from the edit menu. At this point it was obvious that the inlet to the patcher object would receive a signal.

Even if one were to design inside a patcher object "after" creating it, Max "could" know what type of cord to use, as the "outlet of that inlet" would be connected to a certain object inside the "p". So, I feel closer to Mr Lloyd's assumption that it's a visual bug. Again, I was just waiting a confirmation from the developers that it would work OK anyway.


well let me put it like this, if it were [strong]more[/strong] than a visual bug maxmsp would have

been in a state of complete disfunctionality during the last 15 years. :D

so .. what haopen when you save and reload the parent patcher? still no audio cable for ya

well let me put it like this, if it were [strong]more[/strong] than a visual bug maxmsp would have
been in a state of complete disfunctionality during the last 15 years. :D

so .. what haopen when you save and reload the parent patcher? still no audio cable for ya
coming from the inlets??

we really need a how-to sticky post for the danmed markup!

(take it easy, the markup is understood :) although, I didn't get the "-110")

:)) So I think you also agree with the visual bug idea, and give up claiming Max cannot know what surprise is coming in.

And yes, after saving and reloading the parent patcher, still no audio cable there, as you must have apparently seen for yourself during the very last 15 years :D

(take it easy, the markup is understood :) although, I didn't get the "-110") 

:))  So I think you also agree with the visual bug idea, and give up claiming Max cannot know what surprise is coming in.

And yes, after saving and reloading the parent patcher, still no audio cable there, as you must have apparently seen for yourself during the very last 15 years  :D

Don't worry about it dude, it's happening for everyone and makes no difference to the functionality of the patch. Also, I kinda like it often, as the message cords look neater.

With regards to Roman's explanation, it makes sense really; basically what you're doing when you encapsulate is copying the selected objects, pasting them into a new patcher and inserting that new patcher into the parent patch. If there is no built-in memory for the copy/paste-ish function to remember the kind of each connection then max won't know what is coming into the new patcher. It seems like incorporating this might just bog it down a little; arguably unecessarily...........

Don't worry about it dude, it's happening for everyone and makes no difference to the functionality of the patch.  Also, I kinda like it often, as the message cords look neater.

With regards to Roman's explanation, it makes sense really; basically what you're doing when you encapsulate is copying the selected objects, pasting them into a new patcher and inserting that new patcher into the parent patch.  If there is no built-in memory for the copy/paste-ish function to remember the kind of each connection then max won't know what is coming into the new patcher.  It seems like incorporating this might just bog it down a little; arguably unecessarily...........


it is a visual bug caused by max not knowing what is coming in^^

if you disconnect it within the subpatch, then reconnect it, it should change to a signal cord. Probably the same with matrix cords (?)

After you change and re-save, it should stay as a signal cord...?

It's the same "instantiate from the deepest level first, then go up the hierarchy" thing that's built into Max. Generally doesn't cause a problem, but sometimes with named buffers~ and their corresponding access objects (like waveform~), if the object which accesses it is created first, it won't "catch" the creation of the actual buffer, and therefore won't be tied to it until you use the "set" message with it.

> After you change and re-save, it should stay as a signal cord...?

No, it doesn't, and most likely because of the reason you mention after, that a patch is built up from the deepest level. (Although I don't imagine max starts building subpatches which have deepest encapsulation first.)

Anyway, patch chords are there to give a visual feedback only. They're not really there.

This is not any more about whether cords with wrong visualization can be trusted. It is answered confidently, thanks to all of you contributors.

I hope to learn much more from you experienced users in the future correspondences.

This is about some -I think- naive speculations especially after decades of familiarity with this program. (for me, it would be just a couple of years)

I don't understand how you can believe that Max cannot know what type of data is coming, after you put those objects there? And yet it knows what is going to the outlet, but this better be ignored?

Though I had told I didn't like to speculate, it's hard to hold back, isn't it?:

It should be all about the procedure in the creation of the graphics.

Simply, a cord is probably created in a style just due to what outlet of what object it is stemming from. (e.g., fftin~ inside a pfft~ gives cords that never fail to be represented correctly. Likewise, the cords to the outlets are represented correctly unlike those from inlets, as the source object gives out a certain type of cord to that outlet.) The developers must just be reluctant to an add extra test for the situation of inlet objects in the graphics creation process.

And this has nothing to do with "max not knowing what is coming in" tale.

Because it operates correctly (as you assured me in your comments), doesn't it?

How would it operate correctly if it didn't know what was coming? So When would it know what is coming in?? (At this point, it may help to remember that Max is constructing the "code in the background" along with each editing movement of you, as told in the documentation.)

Max should not know what is coming, only when you haven't created the object yet.

A word to the developers: Are you enjoying yourselves hiding in silence, watching us children discuss on things we don't have info about?

This is not any more about whether cords with wrong visualization can be trusted. It is answered confidently, thanks to all of you contributors.
I hope to learn much more from you experienced users in the future correspondences.

This is about some -I think- naive speculations especially after decades of familiarity with this program. (for me, it would be just a couple of years)
I don't understand how you can believe that Max cannot know what type of data is coming, after you put those objects there? And yet it knows what is going to the outlet, but this better be ignored?

It should be all about the procedure in the creation of the graphics.
Simply, a cord is probably created in a style just due to what outlet of what object it is stemming from. (e.g., fftin~ inside a pfft~ gives cords that never fail to be represented correctly. Likewise, the cords to the outlets are represented correctly unlike those from inlets, as the source object gives out a certain type of cord to that outlet.) The developers must just be reluctant to an add extra test for the situation of inlet objects in the graphics creation process.
And this has nothing to do with "max not knowing what is coming in" tale.
Because it operates correctly (as you assured me in your comments), doesn't it?
How would it operate correctly if it didn't know what was coming? So When would it know what is coming in?? (At this point, it may help to remember that Max is constructing the "code in the background" along with each editing movement of you, as told in the documentation.)
Max should not know what is coming, only when you haven't created the object yet.

>> After you change and re-save, it should stay as a signal cord...?

>No, it doesn't, and most likely because of the reason you mention after, that a

>patch is built up from the deepest level. (Although I don't imagine max starts

>building subpatches which have deepest encapsulation first.)

a patch, yes, but not the displaying of the patch.

normally after reload subpatchers do show signal cords. (or dont they for you?)

>No, it doesn't, and most likely because of the reason you mention after, that a
>patch is built up from the deepest level. (Although I don't imagine max starts
>building subpatches which have deepest encapsulation first.)

a patch, yes, but not the displaying of the patch. 

>I don't understand how you can believe that Max cannot know what type

>of data is coming, after you put those objects there? And yet it knows

>what is going to the outlet, but this better be ignored?

well ... you find yourself in this situation with the wrong cable usually when

first connect an inlet to a signal object in a subpatcher - and then connect

in this situation the message connection will not switch automatically

to a yellow cable - unless you reload the patch.

in the case of abstractions and subpatches, it is enough to reload the

subpatcher (you do often unintended, for example when you save a

new version of the subpatcher, or when you change the arguments

with the [patcher] object it might a bit different, and you might call it a

bug that connections are not showing the right type.

speculation? maybe. to me it seems more likely that it has to do

with the inner logic of the program than with lazy developers who

havent noticed and fixed this "bug" over years.

if this turn out a wrong speculation, we still have the option to bitchslap

>I don't understand how you can believe that Max cannot know what type
>of data is coming, after you put those objects there? And yet it knows
>what is going to the outlet, but this better be ignored?

well ... you find yourself in this situation with the wrong cable usually when
first connect an inlet to a signal object in a subpatcher - and then connect
a signal to the subpatcher from outside.

in this situation the message connection will not switch automatically
to a yellow cable - unless you reload the patch.

in the case of abstractions and subpatches, it is enough to reload the
subpatcher (you do often unintended, for example when you save a
new version of the subpatcher, or when you change the arguments
to the subpatcher).

with the [patcher] object it might a bit different, and you might call it a
bug that connections are not showing the right type.

speculation? maybe. to me it seems more likely that it has to do
with the inner logic of the program than with lazy developers who
havent noticed and fixed this "bug"  over years.

if this turn out a wrong speculation, we still have the option to bitchslap
our friends at cycling.


>And this has nothing to do with "max not knowing what is coming in" tale.

>Because it operates correctly (as you assured me in your comments), doesn't it?

operating and displaying a cord are two different things.

>How would it operate correctly if it didn't know what was coming? So When would it know what is coming in??

the object which receives and/or the objects which end something via the connection

try it the other way round: if you have an empty patch and you create an inlet obejct, then

attempt to make a connection from it - how could max know what you are trying to do?

maybe you know wether youre going to bangbang or beeeep, max cannot.

>And this has nothing to do with "max not knowing what is coming in" tale.
>Because it operates correctly (as you assured me in your comments), doesn't it?

>How would it operate correctly if it didn't know what was coming? So When would it know what is coming in?? 

the object which receives and/or the objects which end something via the connection
will tell it max.

try it the other way round: if you have an empty patch and you create an inlet obejct, then
attempt to make a connection from it - how could max know what you are trying to do?

make a subpatch with one inlet, and connect this one inlet to the right inlet of a [*~] object.

the right inlet of [*~] takes numbers or signal.

but it can also take both at a time: you can connect [cycle~] as well as [flonum] to the

right inlet of a [*~], and it will multiply the signal value with the last number received,

so a connection from an inlet in a subpatcher could contain both, a signal connection

and a message connection, in one connection.

now how do you exspect max to display that cable correctly? :)

this is another reason why it is not exactly a "bug".

there is even a third type of connection, such as [tapout~] or [grab] are using, they also

look like message cords but arent. they also can be "mixed" with a signal connection

in a single connection cpming from an inlet in a subpatcher.

the right inlet of [*~] takes numbers or signal. 

but it can also take both at a time: you can connect [cycle~] as well as [flonum] to the
right inlet of a [*~], and it will multiply the signal value with the last number received,
and performs its operation correctly.

so a connection from an inlet in a subpatcher could contain both, a signal connection
and a message connection, in one connection.

there is even a third type of connection, such as [tapout~] or [grab] are using, they also
look like message cords but arent. they also can be "mixed" with a signal connection
in a single connection cpming from an inlet in a subpatcher.

I need hours to answer all in details, so I'll drop a summary for now:

Firstly, none of your arguments invalidate my theory that choice of the method of creating the the graphical representation -and thus, the flaws of it in the special case of the inlets- could be responsable because of choosing the style only and only by the type of the outlet of an object, paralleling the procedure of drawing the cord: always from an outlet to an inlet.

With your last two examples, you neglect that I emphasize "what is coming in" will not be unknown "after you create an object". When you think of classical style programming, do your procedures not be aware of data types in advance, with all the receiving and passing parameters? Don't they parse the incoming bits according to what they expect?

This fact below, is in contradiction with many parts of your writing:

Reloading again and again never corrects the view for me. (Is it not the case for you??)

And also I never said that the developers "haven't noticed" this bug.

>>And this has nothing to do with "max not knowing what is coming in" tale.

>>Because it operates correctly (as you assured me in your comments), doesn't it?

>operating and displaying a cord are two different things.

Never said they were the same. What I'm saying there is "knowing what is coming in" is strongly related with "operating correctly". The excerpt does not contradict with your comment.

But on the other hand, you said this (and everyone agreed):

>it is a visual bug caused by max not knowing what is coming in^^

So I think it's you who correlated "two different things".

Thank you anyway for your endeavour and sensitivity.

With your last two examples, you neglect that I emphasize "what is coming in" will not be unknown "after you create an object".  When you think of classical style programming, do your procedures not be aware of data types in advance, with all the receiving and passing parameters? Don't they parse the incoming bits according to what they expect?

This fact below, is in contradiction with many parts of your writing:
-------------------------------
Reloading again and again never corrects the view for me. (Is it not the case for you??)
-------------------------------

>>And this has nothing to do with "max not knowing what is coming in" tale.
>>Because it operates correctly (as you assured me in your comments), doesn't it?
>
>operating and displaying a cord are two different things.

Never said they were the same. What I'm saying there is "knowing what is coming in" is strongly related with "operating correctly". The excerpt does not contradict with your comment.
But on the other hand, you said this (and everyone agreed):

Thank you anyway for your endeavour and sensitivity.


>Don't they parse the incoming bits according to what they expect?

the target object mostly do typechecks, inlet wont.

the intellect of inlet objects is ranging below the one of politicians.

we have never been talking about inlets and connections here before, and

i am sure (no wait: in fact i am speculating it) that many people who are

reading us are confused now and want to know more about the topic.

btw, when i found out that [grab] and tapping buffer connections work

across levels (and even via send/receive) i was really suprised (and i was

not the only one who was when he firstly saw this)

we have never been talking about inlets and connections here before, and
maybe it time to begin with it.
i am sure (no wait: in fact i am speculating it) that many people who are
reading us are confused now and want to know more about the topic.
btw, when i found out that [grab] and tapping buffer connections work
across levels (and even via send/receive) i was really suprised (and i was
not the only one who was when he firstly saw this)
-110


I may as well mention that you can send audio through the normal max send and receive as well as with send~/receive~ without any noticeable performance penalty.........in fact, s/r seem to use slightly less cpu for this ;) There is a discussion thread knocking around somewhere bout it.

But still, I kind of don't see the point in going too much deeper with this discussion; I can't help thinking that if you think of max as a "normal" programming environment, you're in danger of missing out. It's not particularly "normal", it's a bit odd and that's partly why we all love it :)

I may as well mention that you can send audio through the normal max send and receive as well as with send~/receive~ without any noticeable performance penalty.........in fact, s/r seem to use slightly less cpu for this ;)  There is a discussion thread knocking around somewhere bout it.

But still, I kind of don't see the point in going too much deeper with this discussion; I can't help thinking that if you think of max as a "normal" programming environment, you're in danger of missing out.  It's not particularly "normal", it's a bit odd and that's partly why we all love it :)


Hey, dudes! :) Sorry I was away; couldn't keep up :P

I suppose it's pretty much about time to call for peace.

Mostly due to my somewhat being irritated at some point down the road, the discussion went beyond the inlets to become about logical/wild/educated guesses and so on, and I wish we had a way of turning the "continuation" of this thread into "pm"ing, not to take the community's time for it.

Tim Lloyd, can you post the link to the s/r thread you're mentioning, if it's within your easy reach? Sometimes they be hard to find, though I'll try to.

It's also really intriguing if you're sure about max's not being a "normal" programming environment (I get we're implying its 'background' codes here), and if it's not an illusion casted by its sophistication.

Roman Thilenius, though I think it looked as if I targeted specifically "your" messages, it was not so. ;)

Meanwhile, no developers responded to my implicit calls for an explanation, in several posts in the thread. I was joking of course as I'd asked if they were enjoying the somewhat blind discussion, but so many posts have passed that I'm starting to believe it.

Seriously, I wasn't naively expecting a developer explain some know-hows, but it was easy for one to write a few things that would put an end to the discussion.

Thilenius, when you wrote about your "friends at cycling" ("...we still have the option to bitchslap our friends at cycling") if you were referring to "them", would you please also bitchslap them for me? :)

Tim Lloyd, can you post the link to the s/r thread you're mentioning, if it's within your easy reach? Sometimes they be hard to find, though I'll try to.
It's also really intriguing if you're sure about max's not being a "normal" programming environment (I get we're implying its 'background' codes here), and if it's not an illusion casted by its sophistication.

Roman Thilenius, though I think it looked as if I targeted specifically "your" messages, it was not so. ;) 

Meanwhile, no developers responded to my implicit calls for an explanation, in several posts in the thread. I was joking of course as I'd asked if they were enjoying the somewhat blind discussion, but so many posts have passed that I'm starting to believe it.
Seriously, I wasn't naively expecting a developer explain some know-hows, but it was easy for one to write a few things that would put an end to the discussion.

https://cycling74.com/forums/topic.php?id=25836

When I said "normal" I wasn't meaning to imply I know anything about how it all works internally; I know very little about anything programming-related. I meant just the way it functions for a user is very different to classic text-based progamming. It's object-oriented like many, but is still very different in use. I guess I was just referring to the fact that rather than thinking about functions, classes and all that stuff I know virtually nothing about, I can just not really worry about those things and visualise signal flow and chains of inter-connected processes instead.

Don't worry, I think everyone is cool. This has got to be one of the most chilled forums on the web :)

When I said "normal" I wasn't meaning to imply I know anything about how it all works internally; I know very little about anything programming-related.  I meant just the way it functions for a user is very different to classic text-based progamming.  It's object-oriented like many, but is still very different in use.  I guess I was just referring to the fact that rather than thinking about functions, classes and all that stuff I know virtually nothing about, I can just not really worry about those things and visualise signal flow and chains of inter-connected processes instead.

Don't worry, I think everyone is cool.  This has got to be one of the most chilled forums on the web :)


one innormal programming language (with innormal inlet connections) for innormal people.

about cycling, i think questions about wrong connections should go directly to support@.

one innormal programming language  (with innormal inlet connections) for innormal people.

Was trying to make a corssfader / panner that would accept floats or sig~

I took Tim Lloyds tip - which is fantastic and I will use it elsewhere - and applied it but still have problems with when signal is accepted. Wondering if there are any other neat little tricks?

 Since 2010, cycling74 introduced the typeroute~ object.

otherwise [route float] will also split floats from signals.

you can of course also just connect the inlet object to the right input of a [+~], but then your abstraction will suffer from the same issue you will also have when attempting to randomly connect signals and numbers - alternately or at the same time - to the [+~], where the number value 

would still multiply the signal value after the number connection has been disconnected

. fine within an app - not so fine during programming.

you can of course also just connect the inlet object to the right input of a [+~], but then your abstraction will suffer from the same issue you will also have when attempting to randomly connect signals and numbers - alternately or at the same time - to the [+~], where the number value would still multiply the signal value after the number connection has been disconnected. fine within an app - not so fine during programming.


you can of course also just connect the inlet object to the right input of a [+~], but then your abstraction will suffer from the same issue you will also have when attempting to randomly connect signals and numbers ht

ternately or at the same time - to the [+~], where the number value 

you can of course also just connect the inlet object to the right input of a [+~], but then your abstraction will suffer from the same issue you will also have when attempting to randomly connect signals and numbers https://essentialshoodie.co/alternately or at the same time - to the [+~], where the number value would still multiply the signal value after the number connection has been disconnected. fine within an app - not so fine during programming.

This is a guessing, but I think with encapsulating a part of the patch is rebuilt. In the proces, the inlet object inside the sub patch is created before the connection to the inlet of the sub patch is made. This has to do with the order with which max builds a patch out of a set of instructions. The inlet object is generic, so max won't know at instantiation time if the inlet is handing yes or not a signal, and therefor the patch chord leaving the inlet object will default to a non signal patch chordhttps://essentialshoodie.co/

With your last two examples, you neglect that I emphasize "what is coming in" will not be unknown "after you create an object". When you think of classical style programming, do your procedures not be aware of data types in advance, with all the receiving and passing parameters

With your last two examples, you neglect that I emphasize "what is coming in" will not be unknown "after you create an object".  When you think of classical style programming, do your procedures not be aware of data types in advance, with all the receiving and passing parametershttps://essentialshoodie.co/ 

generic inlet for signals?