[PD-dev] Re: avoiding reuse of vectors in multichannel external

[Kjetil S. Matheussen]

On Tue, 4 Apr 2006, IOhannes m zmoelnig wrote:

> Kjetil S. Matheussen wrote:
>>
>> IOhannes m zmoelnig:
>>
>>>>
>>>> 2)
>>>> 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.