Pd-dev January 2023

pd-dev@lists.iem.at

16 participants
18 discussions

Re: [PD-dev] multichannel signals, preliminary support
by Dan Wilcox 20 Mar '23

20 Mar '23

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

7 27

multichannel signals, preliminary support
by Miller Puckette 10 Mar '23

10 Mar '23

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 are sometimes amusing. cheers Miller

10 45

Request: Transmit control data on signal connections (including multichannel)
by Alexandre Torres Porres 04 Feb '23

04 Feb '23

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

1 1

Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)
by Dan Wilcox 30 Jan '23

30 Jan '23

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

8 12

Variadic function pointers in multichannel code causes M1 Mac and iOS compilation to fail
by Tim Schoen 28 Jan '23

28 Jan '23

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. I’m looking forward to merging the multichannel support into plugdata, it’s a fantastic addition to Pd! Timothy

2 2

help designing multichannel aware externals
by Alexandre Torres Porres 25 Jan '23

25 Jan '23

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/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~

5 12

Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)
by Dan Wilcox 25 Jan '23

25 Jan '23

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) 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/>

1 0

Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)
by Dan Wilcox 24 Jan '23

24 Jan '23

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)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/>

1 0

Re: [PD-dev] Removing [output~]? (was [clone] with subpatches)
by Sebastian Shader 20 Jan '23

20 Jan '23

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

1 0

Re: [PD-dev] Removing [output~]? (was [clone] with subpatches)
by Dan Wilcox 20 Jan '23

20 Jan '23

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. 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/>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev January 2023