Pd-dev February 2023

pd-dev@lists.iem.at

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

Re: [PD-dev] branch names (was Re: figuring out how to get everything merged)
by Dan Wilcox 06 Feb '23

06 Feb '23

I'm fine with branching master, (hard) resetting back to a previous point, merging/cherry-picking portaudio fixes, tagging 0.53-2, then doing a force push. As long as everyone knows ahead of time, we can do a force pull afterwards. Yes, it's best avoided, but is sometimes be needed. Afterwards, maybe current development can be in the branch until ready, ie. feature/multi-channel or develop/0.54, etc? > On Feb 6, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Mon, 6 Feb 2023 09:44:36 +0100 > From: IOhannes m zmoelnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] branch names (was Re: figuring out how to get > everything merged) > Message-ID: <47a595e9-4e0a-12fb-1432-41803fc6c8a8(a)iem.at <mailto:47a595e9-4e0a-12fb-1432-41803fc6c8a8@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 2/5/23 22:37, Miller Puckette via Pd-dev wrote: >> Yep, I originally made a "0.53" branch but then messed it up so badly >> I had to start over - and thought it better to change the name to >> avoid confusion. > > i see. > it seems like the "avoid confusion" did not utterly succeed though ;-) -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 3

Raise error from abstraction
by Matt Barber 06 Feb '23

06 Feb '23

Hi dev list, Could there be a way to give abstractions the ability to raise pd_error() and highlight the abstraction instance with find last error? The reason for it would be that externals often distribute with a mix of binaries and abstractions, and it would be cool to have the user get an error pointer to the abstraction instance rather than the inside of an abstraction, e.g. when they send an unexpected data type. Matt

3 2

figuring out how to get everything merged
by Miller Puckette 06 Feb '23

06 Feb '23

I've back-merged the portaudio update to version 0.53 (tried a week ago but messed it up, hopefully have it correct now). If I understand correctly this will fix the hang-on-macos-13 trouble but won't prevent people from checking callback which also can hang Pd on a Mac. Meanwhile there's Christof's semaphor feature which promises to lower latency (I tried doing this earlier in s_audio_pa.c but found it actually increased latency; not sure what's going on here). The PR is here: https://github.com/pure-data/pure-data/pull/1756 I'm now thinking I should get multichannel inlet~/outlet~ finished first, then study and hopefully incorporate the semaphore PR after that's all working. Then that can be 0.54 (so that 0.53 can be limited to bug-fixing). I wanna get the 0.53 bugfix out as soon as it's pretty sure that it actually fixes things... cheers Miller

5 11

Re: [PD-dev] figuring out how to get everything merged
by Dan Wilcox 06 Feb '23

06 Feb '23

> on close inspection, it turns out that the portaudio/ directories in the > '0.53-2' branch and the 'master' branch are indeed different. > i don't know why and how they have been imported (presumably with the > 'portaudio/update.sh' script, but the > portaudio/portaudio/src/common/pa_gitrevision.h now shows 'unknown' > which is not very helpful) It looks like the script was not used nor was my update/portaudio branch merged which has the define set. The script indeed sets the PA_GIT_REVISION using the update_gitrevision.sh script in the PA repo. I had fixed several small issues with the script itself, mainly due to a file no longer being present in the new portaudio version which may have been why it wasn't used in the end. In any case, I made a small commit directly to the 0.53-2 branch which addresses this and should be pulled into master: dd20389559b3b293a1dd4fdc427f1881e3818bd3 -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

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

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