Pd-list January 2017

pd-list@lists.iem.at

63 participants
84 discussions

Re: [PD] include libpd? (Re: plans for Pd 0.48)
by Peter Nyboer 05 Jan '17

05 Jan '17

> another wishlist from my side (which I wanted to address at PdCon16~ but > somehow didn't manage). > would it be possible to include the libpd glue into the proper Pd sources? Funny - I had a somewhat tangential thought this morning. Something to the effect of it being easier to deploy libpd on embedded devices. I haven’t really looked into it very deeply, hence my uncertainly about whether or not it’s easy, but I know it’s not “juzt 1 klik!” (oh, yeah, I went there). Peter

4 3

Send/Receive topology design
by Jérôme Abel 05 Jan '17

05 Jan '17

Hi, I wonder if there are some differences between cord and wireless messages to deal with musical events (synchro issues). Do you know if it is better to have : - [r NOTE]-->[route $1] objects inside 50 abstractions - or only one [r NOTE] --> [route 0 1 2 3 4 5 6 7 8 9 10 .... ] and cords to these 50 abstractions In term of design it is quite difficult in Pd to find the best way of communications compared to classical programming with "private", "public", "const" attributes range of variables. The $0 would be the "private" attribute for example. In practice, I mixed local and non-local variables inside patches, but if I would like to change the name of messages, add or delete them I need to look inside every abstractions and edit each. I wonder if there is good tips about that. I feel like every messages concerning the functionnalities of an abstraction could be local '$0' connected only with the first upper level. I wonder if cascading [receive] and [route] objects would be less efficient than connecting once objects together but compute them 50 times. I hope it is clear. Thx, -- Jérôme Abel http://jeromeabel.net http://reso-nance.org

4 3

Re: [PD] Send/Receive topology design
by Jérôme Abel 05 Jan '17

05 Jan '17

> what are "synchro issues"? Latency between messages. > the former is easier to patch. the latter will perform slightly better. That's the point. > still end up using [s]/[r] I preferred use send/receive objects to visually encapsulate functionnalities/objects (see parent/child classes), naming them to be more clear when sending messages, and avoid to connect/disconnect cords ... But I understand your tips and it will help me to make choices, thanks. The discussion could be also extend to dealing with a certain number of times the same abstraction. In other programming languages, we use arrays/vectors of objects, it is very clear and powerful. May be the new [clone] could be a good way to implement those features into my patches. Do you know if the performances are the same (wireless and with the first inlet of clone) ? -- Jérôme Abel http://jeromeabel.net http://reso-nance.org

2 1

Re: [PD] include libpd? (Re: plans for Pd 0.48)
by Dan Wilcox 04 Jan '17

04 Jan '17

> On Jan 4, 2017, at 4:00 AM, pd-list-request(a)lists.iem.at wrote: > > the important question is of course, whether the various language > wrappers would be able to use a common libpd.so - if not, the entire > exercise might be moot. On platforms with dynamic linking (*nix, non-iOS), this should be no problem. > afaict, the wrappers currently use static linking, but that might just > be for convenience reasons. Yes. I want to add building dynamic libs but thought to do so with a move to autotools. > it would be interesting to hear peter and dan (or some other libpd > experts) on this. I see two options: 1. Have the pd core, as required by libpd, built as a separate dynamic lib. We could do this with the recent autotools updates relatively easily. Then vanilla as well as libpd and it's wrappers all link to the same lib. Downside is you’re required to install the puredata package to use libpd. This then brings up the idea of could the core be it’s own separate package that the others all use? This leads to option 2. 2. The pd core is split out as a separate library which the gui and the libpd wrappers all use. At that point, it’s basically libpd. Downside here of course is figuring out what makes the most sense in regards to future development (ie. is this desired?) and plainly doing the work. This is probably the best overall approach going forward and was touched upon by some of the discussions at the pd con, but I might be afraid of “breaking things that work.” :) > on the long run, i'm dreaming of pd-vanilla using libpd directly (that > is, dynamically linking against libpd.so like other applications, rather > than statically including it). but that's probably for 0.48-1 :-) Yeah. Thats more of a major change I could see in a possible 0.49. Also, we have some thoughts on updating the API with regards to figuring out the multiple instances problem, so I see needing more time in the roadmap. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Request - Deleting struct instances, progress?
by Derek Kwan 04 Jan '17

04 Jan '17

I suppose since we're doing this about feature requests, I'd like to ask about deleting instances of structs in linked lists =). I've read through the list archive and seen this pop up a few times, one of the issues being brought up being stale pointers if I recall correctly. Is there any progress on this? Would it be possible to just copy over the data from the next node (if it exists) into the requested deleted node and dealloc the original next node? And if a current [pointer] is empty/stale, the next [pointer] the same, just reset to the head as a failsafe? Admittedly, I'm not very familiar with the mechanisms behind [pointer]s so I could be talking complete nonsense so apologies in advance... I suppose that this is a somewhat unrelated question, but what is the [scalar] object supposed to do? Is it just a specific instance of a struct in the linked list? I'd also echo William's words and say thanks for Pd, Miller =) Derek

3 5

Serato timecoded vinyle decoding
by Antoine Villeret 03 Jan '17

03 Jan '17

Hi, I'm wondering if there is a Serato (or xwax) decoding external available for puredata somewhere ? Thanks Antoine -- do it yourself http://antoine.villeret.free.fr

2 2

question about audio I/O with Pd for live WFS system
by Pierre-Olivier Boulant 03 Jan '17

03 Jan '17

Hello everyone, I am in the process of building a wave field synthesis (WFS) system for live sound. I hate hearing wireless microphones come out of a wall of sound and to have bad seats as soon you're off the PA's center when the speakers are too far apart. These are things that were limited by the available processing at the time of analogue consoles. Now with off-the-shelf computing power it's possible to consider real time delay matrices to address this. So far I was doing this on the digital consoles with low track counts, but I would like to expand to more I/O. I'm happy to discuss this with anybody interested in this. I've started prototyping in Pd with the interface running on Lemur to have multitouch control over several sources at a time. Depending on the whole latency and stability it may stay as it is in Pd or I may look into a more dedicated hardware. I would love to have it running on some FPGA but the coding tools are quite expensive and the licensing is *very* closed source and I would like to avoid this. ;) I'll post stuff when I have something I'm happy with. Currently There are quite a few things left on my to do list. I'm trying to minimize latency as much as possible since I'm aiming for a live setup. I'm planning on getting some hardware to move from testing with recorded material to live sources. 6 to 8ms round trip would be great with 32 > 16~20 channels. Since I don't have access to the different options to test, I would have to get myself one. So I'd like to get it right in the first place! ;) There are things I can try and measure on the hardware I have at hand, but I would gladly hear how all this works and if you have any experience with large I/O counts. I have MADI I/O (coax) on my sound desk. I'm thinking of getting a MADI sound card, probably RME. Now I have to figure which sort is best for my application. My first question is not directly related to Pd: USB vs PCIe? It seems like the USB bus adds some latency. I've read somewhere you have 6ms each way on top of the driver and program latency. Is this correct? Is this something that proprietary drivers solve, or is it something impossible to shrink so they don't mention it? I'll try and measure this on my Babyface USB sound card. If so, this would mean building a rack mount computer, the added benefit is that there are much faster CPUs on this sort of rig. then I have to figure out whether a fast quad core with 2 memory channels is better than a slightly slower 6/8 core with 4 memory channels is favourable to work with this number of delay lines (max 32 x 20 [delread4~] ). Where I'm a bit uncertain is with the different settings in Pd. There is the block size; I understand the concept and "realtime" is limited firstly by this value. No problem there. Then there is "latency". I understand it's the time it takes to process. My question is how are the two related? Do they add to each other? Or does the latency setting cover the filling up of the input block? In numbers: if block: 96samples @96kHz (ie. 1ms) and latency: 5ms then the total latency for Pd is 5 / 6 / 7 ms? An other thing, as I understand [pd~] adds some latency. How much? 1 or 2 blocks, an other "latency"'s worth? A different approach I was considering for large systems where I would have more inputs than outputs, would be to breakdown the inputs into bunches of 8 or 10. Send each lot to be processed in a separate instance of Pd and come out on different outputs that would be grouped back together on the mixer of the sound card (ie. RME's Totalmix) which has very low processing time. In other words I would have inputs 1 to 10 and outputs 1 to 16 on instance A and inputs 11 to 20 and outputs 17 to 32 on instance B. Then adding on the sound card output 1 to 17, 2 to 18 and so forth. The sound desk would only see 16 outputs coming back. In instance B, would I need to have [adc~ 11 12 ... 20] and 20 inputs in the audio settings ; [dac~ 17 18 ... 32] and 32 outputs in the audio settings or is there a way to specify in the audio prefs in Pd what channels you want to use and have less I/O in the audio settings? The real question would be: does setting up in the audio preferences more channels than actually used in the instance affect performance? Thanks a lot for your time. Cheers Pierre-Olivier

1 0

Re: [PD] plans for Pd 0.48
by Dan Wilcox 03 Jan '17

03 Jan '17

Howdy José, I updated the overall dialogs, including live updates without the Apply button on OSX. This work is overall finalized and included with Pd 0.47. Can you explain what you mean by: "This really makes programming GUI very time wasting." -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Jan 2, 2017, at 1:17 PM, pd-list-request(a)lists.iem.at wrote: > > From: José Rafael Subía Valdez <jsubiavaldez(a)gmail.com <mailto:jsubiavaldez@gmail.com>> > Subject: Re: [PD] plans for Pd 0.48 > Date: January 2, 2017 at 1:00:05 PM MST > To: "pd-list(a)iem.at <mailto:pd-list@iem.at>" <pd-list(a)iem.at <mailto:pd-list@iem.at>> > > > Hello list, > > just to ask if there is any ruling on the Apple Human Interface Guidelines for the "apply" button in properties. This really makes programming GUI very time wasting. I do not know it what stage is this in. > I know the other topics being discussed are more important in a deeper programming sense, but these little things add up a lot of time when programming. > > cheers

3 7

Re: [PD] Latest PD on Ubuntu
by Dan Wilcox 02 Jan '17

02 Jan '17

This just confirms we need to update the build instructions in INSTALL.txt -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Jan 2, 2017, at 2:50 AM, pd-list-request(a)lists.iem.at wrote: > > if you really need 0.47-1, then i've posted instructions on how to > compile a proper package numerous times on this list. > e.g. here > https://lists.puredata.info/pipermail/pd-list/2016-04/114301.html <https://lists.puredata.info/pipermail/pd-list/2016-04/114301.html>

1 0

Re: [PD] threadsafe multi-instance Pd? (Miller Puckette)
by Pierre Guillot 02 Jan '17

02 Jan '17

That's a great news ! I don't understand what you mean by " If this were (pd_this) were made per-thread". Perhaps that's the point I didn't understand when we were speaking about it at the Pd convention. How can we ensure that an object, a patch or whatever uses the right pd_instance ? Here a concrete example of my problem, if you load a new patch (canvas) in a specific instance, to ensure that the canvas is added to the canvas list of this instance, you need: 1 - Lock a global lock 2 - Set the right instance 3 - Load the patch 4 - Unlock the global lock I don't see how we can remove this global lock without changing the functions' prototypes that use pd_this (by adding a instance's pointer as argument and removing pd_this). > Date: Sun, 1 Jan 2017 15:31:51 -0800 > From: Miller Puckette <msp(a)ucsd.edu> > To: pd-list(a)iem.at > Subject: [PD] threadsafe multi-instance Pd? > Message-ID: <20170101233151.GE21861(a)fuzz.localdomain> > Content-Type: text/plain; charset=us-ascii > > To Pd List, > > Here's my promised followup mail on Pd thread-ability (the hoped for > ability to call Pd instances, via pdlib, from separate threads > concurrently). > > Peter Brinkmann made a suggestion during the Pd convention round-table > discussion that I'll paraphrase here. There is a "pd_this" variable in > m_pd.c, pointing to the current Pd instance. If this were made per-thread, > then it should be possible to run different instances on different threads > simultaneously; the only protection needed would be that each individual > instance should be protected by pdlib with its own lock. > > (There would also have to be a global lock to protect pd_init(), which need > only be called as setup time). > > But there's a snag, because the symbol table is global. It wouldn't help > to > make this per-thread, since calls to pd instances might migrate from > thread to > thread. Instead, we could do 1 of these 2 things: > > 1 (Peter's idea) : make gensym(), pd_bind(), and pd_unbind() threadsafe > using > a lock. Access via gensym() could be nonexclusive, as could locking out > pd_bind() and pd_unbind() during accesses to s->s_thing (we'd have to hunt > down everywhere in the code this is done). > > I think there's a complication: what if you pass a message to an object via > a symbol's s_thing that's in a different instance from the current one > (pd_this) in the thread of the caller? I don't know an easy way to > determine > what pd instance an arbitrary object belongs to. > > OR: > > 2. (another possibility): Go back and make the symbol table be > per-instance. I > tried this earlier and got stumped because classes, which are global to > all Pd > instances, contain a list of selectors (symbols) and their associated > messages. > If the symbol address changes because we switch to a new Pd instance, > messages > (like #N print) no longer are associated with the method (print_new()), so > nothing works. > > I think it's impractical to make classes per-instance, but what about > making > each class maintain a separate list of messages for each Pd instance. When > a new Pd instance is created, we'd go find all the classes, and add a new > message list to each of them for the new instance. > > Then whenever one passes a message (assuming it's not one of s_bang, > s_float, > s_symbol, s_list, or s_anything, which are usually handled by a faster > mechanism), the message passing functions pd_typedmess(), getfn(), etc., > would > have to look up the message list associated with the current pd instance, > and > then look down the list of selectors/methods as before. > > Anyone see anything fatally wrong with this, and/or can option (1) be made > workable and is it better? > > cheers > Miller >

2 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list January 2017