adding outlets to [inlet~] (was How can a signal inlet of an object know if it's receiving a signal)
Ok, the thread was digressing, so I opened a new one... There's a suggestion to add outlets to inlet~ in: https://github.com/pure-data/ pure-data/issues/259 One of the outlets would report if a signal is connected or not (as discussed in the previous thread), the other would route control messages.
I got this itch to try and make a Pull Request for it. First I tried to make it as an external, but couldn't really do it. I tried copying the code of inlet into a new external, without any changes, but I seem to have failed miserably at it.
So I went ahead and started editing Pd's code to see what would happen and if I could do a Pull Request. It was easier to do that, and I was apparently on the right track. So I first added a new control outlet to pass/route all control data fed into an [inlet~] object.
The problem now is that inlet~ still only accepts signals, and will print an error like inlet: expected 'signal' but got 'bang' ... so now what? I figure it'd be crazy to change Pd's code elsewhere, so I looked at it and I assume that this is being set here.
static void *vinlet_newsig(t_symbol *s)
{
t_vinlet *x = (t_vinlet *)pd_new(vinlet_class);
x->x_canvas = canvas_getcurrent();
x->x_inlet = canvas_addinlet(x->x_canvas, &x->x_obj.ob_pd, &s_signal);
Am I right? So I ask, how can I make this external accept ANY kind of message, not just signals?
thanks
2018-03-07 16:24 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2018-03-07 15:42 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
by the way, here's an issue on github
which had been posted on this thread already, haha, sorry
oh, and if someone out there would like to collaborate with me in an external, for easy prototyping, we could start with the current inlet~ structure as a model, but like I said, I couldn't get there, so if anyone succeeds and can send me the code, we could have some fun more easily
cheers
2018-03-07 20:35 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Ok, the thread was digressing, so I opened a new one... There's a suggestion to add outlets to inlet~ in: https://github.com/pure-data/p ure-data/issues/259 One of the outlets would report if a signal is connected or not (as discussed in the previous thread), the other would route control messages.
I got this itch to try and make a Pull Request for it. First I tried to make it as an external, but couldn't really do it. I tried copying the code of inlet into a new external, without any changes, but I seem to have failed miserably at it.
So I went ahead and started editing Pd's code to see what would happen and if I could do a Pull Request. It was easier to do that, and I was apparently on the right track. So I first added a new control outlet to pass/route all control data fed into an [inlet~] object.
The problem now is that inlet~ still only accepts signals, and will print an error like inlet: expected 'signal' but got 'bang' ... so now what? I figure it'd be crazy to change Pd's code elsewhere, so I looked at it and I assume that this is being set here.
static void *vinlet_newsig(t_symbol *s)
{
t_vinlet *x = (t_vinlet *)pd_new(vinlet_class); x->x_canvas = canvas_getcurrent(); x->x_inlet = canvas_addinlet(x->x_canvas, &x->x_obj.ob_pd, &s_signal);Am I right? So I ask, how can I make this external accept ANY kind of message, not just signals?
thanks
2018-03-07 16:24 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2018-03-07 15:42 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
by the way, here's an issue on github
which had been posted on this thread already, haha, sorry
2018-03-07 20:35 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
I assume that this is being set here.
static void *vinlet_newsig(t_symbol *s)
{
t_vinlet *x = (t_vinlet *)pd_new(vinlet_class); x->x_canvas = canvas_getcurrent(); x->x_inlet = canvas_addinlet(x->x_canvas, &x->x_obj.ob_pd, &s_signal);Am I right? So I ask, how can I make this external accept ANY kind of message, not just signals?
Yeah, I've been still trying around and now I'm pretty sure this is where you set the type, and I'm also now assuming there's no way to carry both signals and control data in the same input as it is. This seems to require changes to the core of Pd elsewhere, right? If so, this is where it gets way over my head and I give up.
But how much of a surgical procedure are we talking about?
cheers
Yeah, I've been still trying around and now I'm pretty sure this is where you set the type, and I'm also now assuming there's no way to carry both signals and control data in the same input as it is. This seems to require changes to the core of Pd elsewhere, right?
???
i don't think so ...
[writesf~], [tabwrite~], [snapshot~] etc.
all of them vanilla objects, all take signal AND message inputs
best
oliver
yeah, but it's a completely different picture.
we're talking here about an "invisible" inlet. Please note that [inlet~] does not actually have any real inlet on its box.
I was also assuming and pretty sure it'd be easy to handle both signal and control data for [inlet~], but adding an inlet to a canvas is a completely different process than adding an inlet to an object, and it really has to be either a control inlet or an audio inlet.
Have a look at the code, where I highlighted it, this is it: canvas_addinlet(x->x_canvas, &x->x_obj.ob_pd, &s_signal);
As you can see, you need to specify if it is a signal or not.
And if we're talking about external coding, it is also actually the same deal if you are adding secondary inlets to an object. You cannot have a secondary inlet taking both a signal and a symbol input for instance. I can only assume it is because of the same limitation.
cheers
2018-03-08 4:33 GMT-03:00 oliver oliver@klingt.org:
Yeah, I've been still trying around and now I'm pretty sure this is
where you set the type, and I'm also now assuming there's no way to carry both signals and control data in the same input as it is. This seems to require changes to the core of Pd elsewhere, right?
???
i don't think so ...
[writesf~], [tabwrite~], [snapshot~] etc.
all of them vanilla objects, all take signal AND message inputs
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
-
Alexandre Torres Porres -
oliver