Hello,
Thanks for your reply!
I think my wording of the original problem was wrong -- your solution would work well, but my point is there should be an object (or maybe this should just be the default behavior of [inlet~]) which looks like the following (hopefully the ascii art doesn't get munged on the way out):
[inlet~]
|
|
signal
control data
This way you could pass audio signals and control messages into the one inlet, like you can with something like [snapshot~], say:
[osc~] | | [bang( | / | / |/ [abstraction~ arg1 arg2 etc]
Inside the abstraction the signal would come out of [inlet~]'s left outlet, and the bang would be sent to its right outlet and would be passed to the rest of the abstraction appropriately and at the correct time. This would help complete the abstraction-as-object API and could be a separate object if such a thing would use more overhead than normal [inlet~]...
If I'm not mistaken your solution would allow you to decide whether an inlet is a control or a signal object as it's instantiated in an abstraction at creation time (which I think is what my original wording might have implied) -- I think I'm after something a little different than polymorphism (which is quite an interesting problem on its own). For numbers, [inlet~] already does a good job turning floats into signals.
One other, possibly more extravagant feature that would go even further:
An object like [osc~] seems to "know" when a signal is attached to its inlet or not -- if it's given a creation argument, it will snap back to that, or the last float value it received when the audio signal is disconnected. I'm not sure how to simulate this behavior in an abstraction; I think [inlet~] itself will snap to the last float it received when an audio signal is disconnected, but if you want your abstraction to move back to using the value of its creation argument, there's a problem, since presumably the inlet~ knows nothing about that. One solution I've found is to poll the inlet with an [env~ 2] to look for nonzero values and to switch between using the output of the [inlet~] and a [sig $1] depending on the [env~]'s output, but this assumes that zero is a "non-setting" (as it would snap to the $1 as soon as it received a zero-valued float or [sig~]. The feature I propose would be to allow a float argument to [inlet~] as the default signal to be passed and which is remembered as signals are connected and disconnected to the abstraction from the parent, only until the value stored is changed by a float message. Of course I'm interested in other currently implementable solutions...
Thanks,
Matt
On Wed, Jun 11, 2008 at 8:24 AM, Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 6 May 2008, Matt Barber wrote:
Is there a way to make an abstraction that has one inlet that takes both signal and control messages (like osc~, e.g., or fiddle~ which gets audio and setting info, etc.)?
My solution has been to make an external that contains no objectclass and load it using -lib. It contains this code:
#define ALIAS(y,x) \
class_addcreator((t_newmethod)getfn(m,gensym(x)),gensym(y),A_GIMME,0); t_pd *m = &pd_objectmaker; ALIAS( "inlet.f","inlet" ); ALIAS( "inlet.~","inlet~" );
So after that, Pd 0.40 can instantiate it as [inlet.$1]
If you are stuck with Pd 0.39 you will need to swap it around because [inlet.$1] won't work but [$1.inlet] will.
But this is just an alternative to what Charles Henry said. I prefer mine because the syntax looks better. Then I pass either "f" or "~" as argument to an abstraction. I would later add more single-character suffixes such as "s" and such perhaps, but only to the extent that polymorphism makes sense - first, an analogy has to be made between two types such that one behaviour one one type can be likened to one behaviour on the other. From that point, the two behaviours can be unified, partially or totally, and then [inlet.$1] (or equivalent) becomes useful.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec