[PD] inlet and inlet~

[Matt Barber]

I've been going through the code for this the last couple of days.
I'm new to the code, so this might be for my own understanding than as
any kind of explanation:

There seem to be two main problems -- one is that [inlet] and [inlet~]
are the same class with different creators (and which therefore
utilize different functions) -- it might be that it would break things
to create new classes outright (i.e. there's a reason they're
currently members of the same class), and it would be
hard/undesirable(/impossible?) to add a creator to a class's setup
function externally.

A more serious problem is that the vinlet objects are instantiated as
CLASS_NOINLET which means they have no "main" inlet (the c_firstin
member of the class is switched off), and canvas_addinlet() uses
inlet_new() to forward the subpatch/abstraction inlet to the outlet of
the inlet(~) object -- but since it's no longer a "main" inlet,
CLASS_MAINSIGNALIN() won't work, and any inlet made with inlet_new()
has to decide whether it takes messages or signals/floats - it can't
do both.

The ability of a first inlet to do both seems not to be written into
the the inlet class functions (here I'm talking about the code for any
generic inlet, not [inlet] in particular...), but into object class
functions and the ugen functions:  particularly, an object class's
c_firstinlet and c_floatsignalin members seem to be pretty deeply
ingrained into the design of the functions which determine whether the
first inlet is a signal inlet and should therefore be included in the
ugen graph, and this seems different than any inlets which were added
to the class later (e.g. the code for finding the float value to
convert to a signal in obj_findsignalscalar() is split into code for
the first inlet, which points to a member in the object class's type,
and code for other inlets which points to a float value in a union
which is a member of the inlet struct, not the object class itself).

In other words, at the moment it seems to be just as hard to add the
extra functionality to [inlet~] as it would be to make any ordinary
objectclass whose right inlet could take a signal and a bang message.

I could be very wrong, but I think the external solution would involve
changing some code in unwarranted places, even if new creators,
destructors, and functions could be made for the vinlet class.


BTW, to complicate things, if one wanted abstractions to REALLY work
like objects, then if the abstraction's leftmost inlet were an
[inlet~], it would automatically sprout the right outlet for passing
messages (and this only if it were an abstraction -- you probably
wouldn't want this for subpatches)...

Sorry for the long posts of late.


Thanks,

Matt


On Tue, Jun 17, 2008 at 6:05 AM, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> Hans-Christoph Steiner wrote:
>>
>> Someone could just write new objectclasses that handle both signal
>
> iirc, it's not that simple.
> iolets need deep access to pd-internals.
>
> this is one of the reasons why i have implemented the signal up/downsampling
> in iolet~s within Pd rather than as externals.
> (the other reason was the need to modify [block~] to accept the resampling
> factor...)
>
>> and message, maybe something like:
>>
>> message_inlet~
>
> what does that mean?
>
> and how about [message~] or [ (~ ?
>
> fmasdr
> IOhannes
>