IOhannes m zmoelnig:
what i could glean from the docs/pdf's there is no way a signal inlet could be used for message-input at the same time, is that correct or is there a hack to get this work? i specifically need the left-most inlet to set the objects state etc. what the standard way of dealing with this in PD?
i don't know which docs/pdf's you are exactly reading, but pd has no problem with the first (leftmost) inlet accepting both signals and messages. there are plenty of externals that do that. have a look at [fiddle~] or [bonk~].
No, this is a real problem. I just made a very large patch that based around using the snd external. And because there is no way (as far as we know) to let an inlet (except the first one) accept both signals and messages, each time I needed another inlet, I had to manually move all connectors one step to the right, which made me not add as many inlets as I wanted to. (There are, however, a workaround, which is to let each even-numbered inlet be for messages, and each odd-numbered inlet be for signals. But thats just a hack.) Anyway, theres no rational argument why pd shouldn't be able to support both messages and signals on the same inlet, its probably just programming time that is the argument against. So this is a perfectly valid complaint about PD. (By the way, a bit different approach to solving this problem is to let message-inlets be placed on the vertical line of the object-box, and signal-inlets be placed on the horizontal line of the box. :-) )
Kjetil S. Matheussen wrote:
IOhannes m zmoelnig:
what i could glean from the docs/pdf's there is no way a signal inlet could be used for message-input at the same time, is that correct or is there a hack to get this work? i specifically need the left-most inlet to set the objects state etc. what the standard way of dealing with this in PD?
i don't know which docs/pdf's you are exactly reading, but pd has no problem with the first (leftmost) inlet accepting both signals and messages. there are plenty of externals that do that. have a look at [fiddle~] or [bonk~].
No, this is a real problem. I just made a very large patch that based around using the snd external. And because there is no way (as far as we know) to let an inlet (except the first one) accept both signals and messages, each time I needed another inlet, I had to manually move all connectors one step to the right, which made me not add as many inlets as I wanted to. (There are, however, a workaround, which is to let each even-numbered inlet be for messages, and each odd-numbered inlet be for signals. But thats just a hack.) Anyway, theres no rational argument why pd shouldn't be able to support both messages and signals on the same inlet, its probably just programming time that is the argument against.
hmmm, it is just like you have to know the type of data being sent to a "right" inlet at beforehand, and this inlet will only accept this type. thats how pd currently works (but i agree that it is not really helpful)
and that is what makes it so hard to code objects which accept anything on their inlets. otoh, it is possibly via proxy inlets and there might be a tiny chance that something similar works with signals too. btw, flext makes the use of these extended features a lot simpler.
however: intuitivly, i would consider an object which lots of mixed inlets to be badly designed anyhow: i think it is quite ok of pd that it enforces some thought on how to create the objects API (which inlet/outlet does what), instead of "just allowing anything".
So this is a perfectly valid complaint about PD. (By the way, a bit
i haven't doubted that.
however, the original mailer said: "there is no way a signal inlet could be used for message-input" that they know of and "i specifically need the left-most inlet" to accept both signals and messages. since the left-most inlet DOES accept both signals and messages i consider this special complaint as void.
fmga.sdr. IOhannes
On Tue, 4 Apr 2006, IOhannes m zmoelnig wrote:
however: intuitivly, i would consider an object which lots of mixed inlets to be badly designed anyhow: i think it is quite ok of pd that it enforces some thought on how to create the objects API (which inlet/outlet does what), instead of "just allowing anything".
It's not "thought".
Do not mistake "thought" and what has simply happened.
Just because there's a restriction in place doesn't mean that it's been designed for your own good.
The only reason why a regular inlet can't have two methods registered to it, is because that was how MAX was designed in 1987, and it was designed that way because:
* object-oriented theory doesn't know about inlets so the extra (non-left) inlets concept got inserted as some sort of automatic messagebox so that it appears that there's only one inlet at the level of defining methods.
* Pd (and almost all OOP languages) doesn't allow dispatch based on type of argument, so somehow the type of $1 got duplicated as a selector, which leads to all sorts of troubles as we've noticed...
That's it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 4 Apr 2006, IOhannes m zmoelnig wrote:
Kjetil S. Matheussen wrote:
IOhannes m zmoelnig:
what i could glean from the docs/pdf's there is no way a signal inlet could be used for message-input at the same time, is that correct or is there a hack to get this work? i specifically need the left-most inlet to set the objects state etc. what the standard way of dealing with this in PD?
i don't know which docs/pdf's you are exactly reading, but pd has no problem with the first (leftmost) inlet accepting both signals and messages. there are plenty of externals that do that. have a look at [fiddle~] or [bonk~].
No, this is a real problem. I just made a very large patch that based around using the snd external. And because there is no way (as far as we know) to let an inlet (except the first one) accept both signals and messages, each time I needed another inlet, I had to manually move all connectors one step to the right, which made me not add as many inlets as I wanted to. (There are, however, a workaround, which is to let each even-numbered inlet be for messages, and each odd-numbered inlet be for signals. But thats just a hack.) Anyway, theres no rational argument why pd shouldn't be able to support both messages and signals on the same inlet, its probably just programming time that is the argument against.
hmmm, it is just like you have to know the type of data being sent to a "right" inlet at beforehand, and this inlet will only accept this type. thats how pd currently works (but i agree that it is not really helpful)
and that is what makes it so hard to code objects which accept anything on their inlets.
otoh, it is possibly via proxy inlets and there might be a tiny chance that something similar works with signals too.
I doubt it. I have tried very hard to make it work, asked questions on this list, and never heard of anyone ever made that work. I'm very positive its not possible.
btw, flext makes the use of these extended features a lot simpler.
Yeah, I looked at the flext source when making the k_guile and snd externals (Thomas is acknowledged in the README file). Both k_guile and snd use proxy inlets just like flext. But those kinds of proxy inlets does not work for signals.
however: intuitivly, i would consider an object which lots of mixed inlets to be badly designed anyhow: i think it is quite ok of pd that it enforces some thought on how to create the objects API (which inlet/outlet does what), instead of "just allowing anything".
Depends on the situation. The patch I talked about would probably have been more elegant if I had read the OSC messages directly inside SND instead of receving them via signal inlets (message inlets have other implications again). However, since we were 4 people working on the patch, and I was the only one knowing scheme, I could not do that. And I'm sure there are lots of other situations were mixed inlets makes sense. You can't really know.
-
IOhannes m zmoelnig -
Kjetil S. Matheussen -
Mathieu Bouchard