> On Jan 18, 2023, at 2:41 AM, pd-dev-request(a)lists.iem.at wrote:
>
> "MC is not an entirely new API for MSP objects. Instead it is built on top
> of the existing MSP API. (...)
This name prefix / wrapper approach seems like an implicit way of what Miller is looking at doing more explicitly via [clone]. Either way, they have also avoided having to update each object directly.
> so it seems they did not create new codes and new objects, just adapted,
> and even made it …
[View More]possible for it to open a special help patch but it's all
> the same object and you can use this API to generate externals - if I get
> things correctly...
Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation.
I believe this doesn't require any changes in libpd, thankfully.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
To Pd dev -
I've pushed what I think is working support for multichannel signals. Many
objects haven't yet been adapted to deal with them, but there are enough to
at least test the concepts: lop~, send~, receive~, and (ugh) clone are
multichannel-aware, and new pack~ and unpack~ objects are provided to
combine and split signal channels.
I've put a couple of example patches on
http://msp.ucsd.edu/tmp/multichannel-tests.tgz
... the interplay between multichannel inlets and outlets and clone
…
[View More]are sometimes amusing.
cheers
Miller
[View Less]
This is something I wanted to request for a while, and now with the
mutlichannel connections it seems to be the right time to do this. This is
also something that works in MAX (though I am not sure how it is managed in
multichannel signals).
In MAX you have inlet/outlet objects that deal with both messages and a
subpatch can send on a single connection both audio and control messages.
MAX also has the [typeroute~] object that can split audio signal and
control messages, which can be used in …
[View More]this case.
We already have half of the stuff working in Pd. The [inlet~] object
already splits signal and control data with the 'fwd' argument. What we
miss is the ability of [outlet~] also accept and send this through a single
audio connection.
Use cases? This is really useful for a "modular like" system, with
abstractions that work like modules with visual controls (GOP) connected to
each other. I am designing a system like this now, inspired by euro-rack
synth modules by the way. I wouldn't like to extend this discussion so much
and bore you people with technical details of this project. It really seems
like a great convenience that people would like and I bet others will come
up with more use cases and special cases where this really saves the day.
For my purpose, what we have to do now is create more outlets / inlets and
connect them, or use global sends/receives. I have an external that gets
'$0' of a parent patch which also helps, but I think using this makes
things easier and more powerful. I would have the liberty to design more
functional modules.
This seems especially useful with multichannel connections, where we could
also send control parameters for a specific channel, which can be retrieved
inside [clone] with our already existing [inlet~ fwd] configuration.
What do you say?
cheers
[View Less]
I was trying to think of a further biblical [moses] analogy, but I guess there is probably a [moses~] already.
Maybe [cross~] / [uncross~] ala Ghostbusters... "don't cross the streams"
> On Jan 23, 2023, at 11:05 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Mon, 23 Jan 2023 18:53:12 -0300
> From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>>
> To: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>>
> …
[View More]Cc: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>>, pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals,
> preliminary support)
> Message-ID:
> <CAEAsFmgjZmnQj9iApGMj7JnED96DdH9vx0B2DWps1sv2-zwEyA(a)mail.gmail.com <mailto:CAEAsFmgjZmnQj9iApGMj7JnED96DdH9vx0B2DWps1sv2-zwEyA@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> I find snake~ and unsafe~ a bit weird but amusing, I kinda like idea of
> typing that object name and read it in a patch
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
Hi,
I’m not sure if you’re aware of this already, but some of the new multichannel code in d_ugen.c does not compile on Apple Silicon, because of the use of variadic arguments inside the function pointer t_gotfn.
I’ve solved this temporarily by creating a separate definition for t_gotfn with two arguments, though this might not be a clean/permanent solution.
In m_pd.h:
In ugen.c:
If needed I’m willing to help look for a better solution, though I’m not very familiar with the ugen code.
…
[View More]
I’m looking forward to merging the multichannel support into plugdata, it’s a fantastic addition to Pd!
Timothy
[View Less]
Hi smart pd-dev people, please help me. I'm miserably failing in designing
new externals with the amazing new multi-channel feature.
Getting inspired by some of the MAX objects, for fun and for starters I
thought I'd clonen [mc.list~], which is kinda like the new [pack~] but you
can set the values as arguments. It would also allow us to use the list box
to set all values.
My first and only 'mc' external so far is [nchs~], see -->
https://github.com/porres/pd-else/blob/master/Classes/Source/…
[View More]nchs~.c I
already mentioned it and said it'd be cool to have it in Vanilla. It
outputs a float value but I wanted, as a first step, to adapt it to output
a signal value instead, but I can't do not even that, let alone have a new
external that outputs a multichannel signal. From the [nchs~] code, I just
use the 'dsp method' to get 'sp[0]->s_nchans' (number of channels) and call
a bang function that outputs the float.
If I create a 'perform' method to get number of channels as a signal, Pd
blows up, and I don't know what I'm doing wrong as I'm doing what I do with
every other regular external. Not that I wanted a signal output, I'd rather
have the float output, but I expected this to work and I can't see the
problem. I am assuming multichannel externals are different and I don't
really know the secret or the recipe yet to mess with them. Check code
below.
*static* t_int *nchs_perform(t_int *w){
t_check *x = (t_check *)(w[1]);
*int* n = (t_int)(w[2]);
t_sample *in = (t_sample *)(w[3]);
t_sample *out = (t_sample *)(w[4]);
*while*(n--)
*out = x->x_nchans;
*return*(w+5);
}
*static* *void* nchs_tilde_dsp(t_check *x, t_signal **sp){
x->x_nchans = sp[0]->s_nchans;
dsp_add(check_perform, 4, x, sp[0]->s_n, sp[0]->s_vec, sp[1]->s_vec);
}
I can't imagine the further challenges to output or treat multichannel
signals, but I'd like to start by clarifying this.
funny enough, [pack~]/[unpack~] do not have 'perform' methods so I can't
figure this out.
Thanks a lot.
cheers~
[View Less]
Max (I think) had the suggestion of using established audio tech terms -> [snake~] and [breakout~] where "breakout" refers to a breakout box from a physical audio snake. It might translate a bit better than a non-word like "unsnake" ?
You could take it further to [breakin~] / [breakout~] but I don't believe "breakin" is really used in the audio context, at least the part hat I deal with.
For a single channel, [tap~] makes conceptual sense to me but then this is perhaps a different (water) …
[View More]metaphor?
No matter what is chosen, it's nice to go through the options a this is one of these parts of the API that can't be (easily) changed later on. For my own projects, I offend agonize over the naming at the beginning.
> On Jan 25, 2023, at 7:53 AM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 3
> Date: Tue, 24 Jan 2023 20:48:52 -0800
> From: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>>
> To: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>>
> Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals,
> preliminary support)
> Message-ID: <Y9C0tCTVCxWeMaqd(a)ucsd.edu <mailto:Y9C0tCTVCxWeMaqd@ucsd.edu>>
> Content-Type: text/plain; charset=iso-8859-1
>
> OK... now I'm hesitating between "snake~ in", "snake~ out" and "snake~ tap"
> or "join~", "split~", and "tap~"...
>
> Former is more colorful (and crowds the namespace less). Latter might be
> easier for non-native English speakers to deal with?
>
> cheers
> Miller
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
Another option is an object like [clone] which instantiates for multichannel handling only... could simply be called [mc~] and take specific creation names for functionality, otherwise creates the objects for mc handling, so works like [text] etc:
[mc 4 osc~] -> creates 4 [osc~] instances inside
[mc pack 4] -> unpacks 4 channels
[mc unpack] -> packs 4 channels
[mc tap 1] -> taps single channel 1 out of the 4 channels
...
> On Jan 23, 2023, at 6:33 PM, pd-dev-request(a)…
[View More]lists.iem.at wrote:
>
> Message: 1
> Date: Mon, 23 Jan 2023 09:02:33 -0300
> From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>>
> To: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>>
> Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals,
> preliminary support)
> Message-ID:
> <CAEAsFmiwCAPQn-4LUiJLMKT3KDVvPzLiqsuQK4W4mtzD657_iw(a)mail.gmail.com <mailto:CAEAsFmiwCAPQn-4LUiJLMKT3KDVvPzLiqsuQK4W4mtzD657_iw@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> I actually do like pack~/unpack~ a lot, because they have control
> counterparts and also MAX uses something similar but prepends 'mc.' to it,
> so [mc.pack~] and [mc.unpack~] are exactly what [pack~] and [unpack~] do!
>
> On the other hand, if we really want to avoid this collision badly, maybe
> we could use a similar convention to specify an object that is multichannel
> aware, something quite new in the pd world. I'm not saying we should use
> the same 'mc.' convention. I know using "." is not much common in the Pd
> world, but in ELSE I use it and have plans to add many multichannel aware
> externals that would make things simpler and while we don't have our
> [clone] solution for internal and external objects, like a muti channel
> [dac~] object called [dac.mc~]. I like it better that the mc comes later as
> objects would be alphabetically next to their multichannel version. This
> would also prevent people from thinking it's an external from Cyclone that
> mimics the original.
>
>
> So... what about [pack.mc~] and [unpack.mc~]?
>
> maybe just [packmc~] and [unpackmc~] as well... but I like "."
>
> cheers
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
Maybe yet another outlet could be added to [inlet~] to indicate that a
signal is connected, so that 'magic numbers' don't have to be used?
Isn't that one of the things being added to the API? If so it would be nice ifabstraction authors could have access to it too anyways.
-Seb
>Oh, I misunderstood the last mail. I do think the panel can just be
>a slider+number box (or just a number box) plus a "mute" button that
>toggles mute on and off. (That could be a graphical …
[View More]toggle instead
>of a bang if people find that more intuitive - I hadn't thought of that).
>
>By the way, I'm coming around to your idea just to 'detect' when a second
>audio inlet is disconnected and switch the object into mono mode in that
>case - that's pretty smart :)
>
>cheers
>Miller
>
>On Fri, Jan 20, 2023 at 01:49:24PM -0300, Alexandre Torres Porres wrote:
>> I use it all the time as well, but I'm not sure what you mean. You say you
>> want the bang button instead of a toggle? You say you want me to keep the
>> bang message into it to it changes the state of the toggle?
>>
>> What I said is that I doubt people were using external controls via
>> messages into the object to make me bother and keep the bang message.
>>
>> what do you say?
>>
>> cheers
>>
[View Less]
Looks good to me. It seems similar to the rjlib [soundinput] and [soundoutput] abstractions which I use with PdParty:
> On Jan 20, 2023, at 1:09 AM, pd-dev-request(a)lists.iem.at wrote:
>
> This seems simple, better and is more versatile and seems like a good
> candidate for a new Vanilla [output~] abstraction that is really useful for
> day to day usage. See screenshot below and find the patch attached. Please
> give me feedback to see if I'm going in the right direction. …
[View More]If it is ok I
> will make a PR and update the documentation.
>
>
> [image: Screen Shot 2023-01-19 at 21.07.18.png]
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]