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@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