Matt Barber wrote:
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.
actually it is rather trivial, see attached diff.
this however is a
IOhannes m zmoelnig wrote:
Matt Barber wrote:
actually it is rather trivial, see attached diff.
oops, seems my test-patch was missing something :-)
not _that_ trivial probably...
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
Someone could just write new objectclasses that handle both signal
and message, maybe something like:
message_inlet~
message_outlet~
.hc
On Jun 12, 2008, at 4:09 PM, Matt Barber wrote:
Right, I had thought about a third outlet which sends a 1 or a 0
depending on connection state --
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.
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
Matt Barber wrote:
Hello,
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
Right, I had thought about a third outlet which sends a 1 or a 0
depending on connection state -- somehow the float argument seems
better integrated with the default behavior of other objects, and much
simpler to use. I think the reason is that floats coming in are
already promoted to signals; in
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
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
No... I hope to figure out a good way to permit that. Meanwhile, there's
also a bug in that inlet~ doesn't take numbers correctly (doesn't
promote them to signals)
cheers
Miller
On Tue, May 06, 2008 at 10:07:04AM -0400, Matt Barber wrote:
Hello,
Is there a way to make an abstraction that
Hello,
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.)? It's part of the API for objects;
it seems to me there ought to be a way to do this with abstractions as
well. I'm
It piqued my curiousity this morning...
whether you could use $1 arguments in the name of an object. So, I
made a abstraction this morning called inle.pd and it works.
You can instatiate the abstraction as
[inle t]
or
[inle t~]
I don't think this approach is at all useful, though.
Chuck
On
12 matches
Mail list logo
