Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

Fw: Aw: Re: [sc-dev] Re: [sc-dev] sc-dev meeting minutes
by Christof Ressi 28 May '19

28 May '19

> ~ambiServer = { arg i; Server.embed(Synth("ambi", [\out, ~ambiBus[i]]), addr: ~myAddr[i], ~myOptions, synth: Synth("test")); } ! 4; d'oh. this should read: ~ambiServer = { arg i; Server.embed(Synth("ambi", [\out, ~ambiBus[i]]), addr: ~myAddr[i], ~myOptions); } ! 4; --- and I just want to add that this is really orthogonal to the Supernova approach, it's actually possible to have both. Christof > Gesendet: Dienstag, 28. Mai 2019 um 12:09 Uhr > Von: "Christof Ressi" <christof.ressi(a)gmx.at> > An: sc-dev(a)lists.bham.ac.uk > Betreff: Aw: Re: [sc-dev] Re: [sc-dev] sc-dev meeting minutes > > > Where it is unfortunate (now) is that, for each server that needs to access memory, each server needs to allocate it’s own. > > yes, embedding Servers doesn't solve this problem either but often we have more than enough RAM anyway. > > > > Physical Output buses, obviously, get summed together for you when writing to the sound card, but this is different than what happens if two instances of scsynth write to then same virtual bus, and I think is something that will lead to confusion with this approach. Not that it can’t be overcome, but I do think it is an issue. Especially in case where you are writing sound to many buses that need additional processing done (for example, writing output with Amibisonic encoding that needs to be decoded for each instance of scsynth). > > > that's exactly where embedded Servers can help. here's a fictional example: > > ( > // SynthDef to produce a 3rd order ambisonic signal in a seperate Server instance > SynthDef("ambi", { arg out; > Out.ar(out, Server.ar(numOut: 16)); > }).add; > > // create 4 ambisonic busses > ~ambiBus = { Bus.audio(numChannels: 16) } ! 4; > > // create 4 NetAddress > ~ambiAddr = { arg i; NetAddr.new("localhost", 57111 + i) } ! 4; > > // create some Server options if needed (numInputBusChannels/numOutputBusChannels can be deduced from the Ugen) > // ~myOptions = > ) > > // create 4 Servers with the fictional "embed" method: Synth, name, addr, options, clientID > // internally, each Server instance writes to its 16 hardware outputs and the Ugen will route this to the given audio bus (= ~ambiBus[i]) > > ~ambiServer = { arg i; Server.embed(Synth("ambi", [\out, ~ambiBus[i]]), addr: ~myAddr[i], ~myOptions, synth: Synth("test")); } ! 4; > > // now we can encode each ~ambiBus signal and finally decode all of them. > > --- > > does this make sense? we actually do stuff like this in Pd with [pd~]. > > the key point is to realize that Server.ar really is a Unit generator (a block box which consumes/produces audio). Internally, the Ugen would probably buffer the inputs and outputs, so we wouldn't need to implement any audio bus locking. the procedure is: > a) lock the buffer > b) copy Ugen input to buffer, copy last Server result to Ugen output. > c) unlock and signal the embedded Server to process the next block > we would get a constant delay of one block but we should never have to wait for the embedded Server. > > treating a Server like a UGen means we can freely (and dynamically!) interconnect different Server instances in Supercollider and also nest them arbitrarily. Running each Server on its own thread is a very simple solution which doesn't scale (having too many threads can lead to performance issues), but for many use cases it would be fine I guess. > > I can probably hack together a prototype of this in a day or so, maybe I do this in summer :-) Of course, the Supernova approach is vastly superior but also though to implement. > > Christof > > > > Gesendet: Dienstag, 28. Mai 2019 um 04:53 Uhr > > Von: josh(a)realizedsound.net > > An: sc-dev(a)lists.bham.ac.uk > > Betreff: Re: [sc-dev] Re: [sc-dev] sc-dev meeting minutes > > > > > > > > > On May 27, 2019, at 7:47 PM, christof.ressi(a)gmx.at wrote: > > > > > > I've written a multithreaded virtual modular synthesizer and it is quite easy as long as the thread management is done manually (the user says: please run this node on thread X) but it gets hairy when it should be done automatically (e.g. based on average CPU use). > > > > > > --- > > > > > > but there's also a totally different possibility of concurrency: embedding Scsynth instances within itself. In Pd there's an object [pd~] which runs a seperate Pd instance in another process. You can send/receive audio and messages, but you can't immediately share data (although there's the "shmem" external for shared memory). The reason Pd has to run in a seperate process is that it is a fundamentally single-threaded program with lots of global state (but there have been recent efforts to overcome this limitation utilizing thread local storage). > > > > > > AFAICT, Scsynth on the other hand has very little (mutable) global state: gUnitDefLib, gBufGenLib, gPlugInCmds and those dictionaries can actually be shared across instances (they just have to be made thread-safe). This means it would be possible to run a complete seperate Scsynth instance inside a single Ugen in a dedicated thread. The parent and child instance(s) don't share any data, but they can exchange audio data (and maybe also control data). You can basically achieve the same thing with running several Scsynth processes and connecting them with Jack, but doing it all in Supercollider makes the routing much easier and you can exchange audio with guaranteed minimal latency. > > > > > > the only thing it takes is writing a fake audio driver and export a function with which you can tick the driver, similar to the callback functions of the real audio backends. the UGen would just need to call this function in the perform routine; actual Server creation (+ options) could be handled asynchronously with unit commands (like VSTPlugin). it could look like this: > > > > > > // SynthDef to process a stereo audio signal with a seperate Server instance > > > ( > > > SynthDef("test", { arg in, out; > > > Out.ar(out, Server.ar(in: In.ar(in, 2), numOut: 2)); > > > }).add; > > > ) > > > > > > // open Server inside a Synth node > > > ~myServer = Server.new("foo", ~myAddr, ~myOptions, synth: Synth("test")); > > > > > > > > > would someone find this useful or is this just ridiculous? :-D > > > > How would this address the issue of shared memory / busses between instances that are controlled by the dummy server? > > > > Personally, I already manage different instances of scsynth that don’t need input / output from other instances to take advantage of multiple cores. Where it is unfortunate (now) is that, for each server that needs to access memory, each server needs to allocate it’s own. > > > > Physical Output buses, obviously, get summed together for you when writing to the sound card, but this is different than what happens if two instances of scsynth write to then same virtual bus, and I think is something that will lead to confusion with this approach. Not that it can’t be overcome, but I do think it is an issue. Especially in case where you are writing sound to many buses that need additional processing done (for example, writing output with Amibisonic encoding that needs to be decoded for each instance of scsynth). > > > > Best, > > > > Josh > > > > > > > > also, with the exported tick function it wouldn't be too hard to also embed Supercollider in a VST plugin or Pd external. > > > > > > Christof > > > > > >> Gesendet: Dienstag, 28. Mai 2019 um 02:07 Uhr > > >> Von: jamshark70(a)gmail.com > > >> An: sc-dev <sc-dev(a)lists.bham.ac.uk> > > >> Betreff: Re: [sc-dev] Re: [sc-dev] sc-dev meeting minutes > > >> > > >> On Tue, May 28, 2019 at 6:37 AM <amindfv(a)gmail.com> wrote: > > >>> I see a few routes for the _hypothetical_ unification: > > >>> - There's the route of putting code from scsynth "into" supernova > > >>> - The reverse (supernova code "into" scsynth) > > >>> - Reimplement ParGroups in scsynth without using supernova code at all > > >> > > >> My opinion is that this -- reimplementing -- is probably the best way. > > >> See below. > > >> > > >>> - Just start using supernova for everything, and fix as many bugs as needed for everyone to be happy with that route > > >> > > >> The major bug here is -- I recall reading in Tim's master's thesis > > >> that supernova builds a dependency graph internally for thread > > >> allocation. The dependency graph must be updated when groups (parallel > > >> or not) are moved. > > >> > > >> It happens that I sometimes issue a lot of group-moving commands in > > >> quick succession (MixerChannel automatically reorders groups according > > >> to channel output and pre-/post-send routing). I've seen in a number > > >> of cases where creating and deleting a large number of mixer channels > > >> (e.g., a section transition in performance) causes supernova to crash. > > >> > > >> I believe there is some stress condition that causes supernova's > > >> dependency graph calculation to break. > > >> > > >> If this is not fixed, then reusing supernova code is IMO a non-starter. > > >> > > >> So far, the dev community has treated this part of supernova as a > > >> black box. We'll have to open it up and fix it (and it's difficult to > > >> reproduce -- I could crash it 80% of the time with a large, complex > > >> live set, but I've failed to create a smaller reproducer), or create a > > >> new implementation that simply doesn't use this code. > > >> > > >> hjh > > >> > > >> _______________________________________________ > > >> sc-dev mailing list > > >> > > >> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/ma… > > >> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ > > >> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ > > >> > > > > > > _______________________________________________ > > > sc-dev mailing list > > > > > > info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/ma… > > > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ > > > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ > > > > > > _______________________________________________ > > sc-dev mailing list > > > > info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/ma… > > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ > > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ > >

1 1

Re: [PD-dev] Pd-dev Digest, Vol 169, Issue 5
by Dan Wilcox 27 May '19

27 May '19

I can confirm that it's an issue with Tk 8.5 built on macOS 10.14. This will most like *not* be fixed as 8.5 is pretty old nor do I have any desire to look into fixing it with a patch right now. The original idea behind "make app" was that the vast majority of people building Pd should not need to build Tk, however it's fallen a bit behind. What we can do is update the pre-compiled Wish.app that is included with Pd so "make app" produces the canonical Pd.app again. It's still using the old 8.4 Wish which no longer runs on macOS. Miller's release builds still work fine, so I've asked him to send a copy of his Wish.app we can use. Another option you can use is to simply use a newer version of Tk, say 8.6. > On May 11, 2019, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > I am having similar issue here. > On Wed, 1 May 2019 at 09:34, Dan Wilcox <danomatika(a)gmail.com <mailto:danomatika@gmail.com>> wrote: > >> 64 bit is the default for compiling the Pd core. Your problem is that you >> are using the old canonical 32-bit Tk Wish as provided with Pd which has >> not been updated with Miller's 8.5.19 build yet (as far as I remember). >> >> You need to build Tcl, TK, & Wish yourself and then use it to build >> Pd.app. This is outlined in mac/README.txt >> >> Your steps should be: >> >> Build Pd >> >> ./autogen.sh >> ./configure >> ./make >> > So after I have done the above, then > > >> Build Wish (and leave it around for reuse) >> >> mac/tcltk-wish.sh --leave 8.5.19 >> > > when I am trying to do this part, unfortunately towards the end, my > terminal prints out something like this > Installing Tk library files to > /Users/osamupang/pure-data/mac/tk8.5.19/macosx/../../build/tk/Deployment//Library/Frameworks/Tk.framework/Versions/8.5/Resources/Scripts/ > Installing Ttk library files to > /Users/osamupang/pure-data/mac/tk8.5.19/macosx/../../build/tk/Deployment//Library/Frameworks/Tk.framework/Versions/8.5/Resources/Scripts/ttk/ > Installing library image files to > /Users/osamupang/pure-data/mac/tk8.5.19/macosx/../../build/tk/Deployment//Library/Frameworks/Tk.framework/Versions/8.5/Resources/Scripts/images/ > Installing message catalog files to > /Users/osamupang/pure-data/mac/tk8.5.19/macosx/../../build/tk/Deployment//Library/Frameworks/Tk.framework/Versions/8.5/Resources/Scripts/msgs/ > ln: invalid option -- 'h' > Try 'ln --help' for more information. > make[2]: *** [install-tk] Error 1 > make[1]: *** [tk] Error 2 > make: *** [embedded-deploy] Error 2 > > edit: as I am writing this, I also find a work around to the above problem, > basically I did this to get into the homebrew environment: > > brew sh > mac/tcltk-wish.sh --leave 8.5.19 > > (I am not sure other mac users are having the same problem as I do, but if > it is, it might be worth to add this work around to INSTALL.txt or > mac/README.txt ?) > however after the next steps > > mac/osx-app.sh --wish Wish-8.5.19.app 0.49-1 > open Pd-0.49-1.app/ > > I am having the same issue as Alexandre, where I can't put any object in Pd, > and when I am trying to resize the window, it just went dark and stopped > responding. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] issues compiling Pd in macOS mojave
by Dan Wilcox 11 May '19

11 May '19

64 bit is the default for compiling the Pd core. Your problem is that you are using the old canonical 32-bit Tk Wish as provided with Pd which has not been updated with Miller's 8.5.19 build yet (as far as I remember). You need to build Tcl, TK, & Wish yourself and then use it to build Pd.app. This is outlined in mac/README.txt Your steps should be: Build Pd ./autogen.sh ./configure ./make Build Wish (and leave it around for reuse) mac/tcltk-wish.sh --leave 8.5.19 Build Pd-0.49-1.app mac/osx-app.sh --wish Wish-8.5.19 0.49-1 > Hi, I'm doing > > ./autogen.sh > ./configure > ./make > ./make app > > but then I can't open Pd in Mojave as it seems to compile for an > incompatible 32 bits. Hence, I'm emailing the zipped package and opening it > in another computer with an older macOS to test it. > > Can we make it compile for 64 by default? And what do I need to do to > configure it to do so? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 8

Compile i386 externals on Linux amd64
by Roman Haefeli 01 May '19

01 May '19

Hey all Is there an easy way to use the pd-lib-builder Makefile to compile externals for Linux i386 on Linux amd64? Currently, I'm using a Debian Stretch i386 KVM VM specifically for this purpose. But since I am successfully cross-compiling for Windows 32bit and 64bit targets with mingw compiler, I was wondering if it was as easy to cross-compile for Linux as easily. Roman

3 4

Re: [PD-dev] issues compiling Pd in macOS mojave
by sebfumaster＠aol.com 01 May '19

01 May '19

Hi, I thought I might mention that I also haven't been able to compile a useable Tk 5.19 to use with Pd after switching to Mojave, I'm still using versions I've compiled from El Capitan. (It always has the same issues that you mention) -Seb

1 0

Re: [PD-dev] CAF file support?
by Dan Wilcox 30 Apr '19

30 Apr '19

Hah, my other thought was to add an optional libsndfile backend to [soundfiler], [readsf~], & [writesf~]... > On Apr 26, 2019, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > On 23/4/19 3:58 am, IOhannes m zmölnig wrote: >> so yes. CAF would be a nice addition to support, although it can be a >> very complex format. > > https://github.com/erikd/libsndfile/blob/master/src/caf.c <https://github.com/erikd/libsndfile/blob/master/src/caf.c> -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

issues compiling Pd in macOS mojave
by Alexandre Torres Porres 30 Apr '19

30 Apr '19

Hi, I'm doing ./autogen.sh ./configure ./make ./make app but then I can't open Pd in Mojave as it seems to compile for an incompatible 32 bits. Hence, I'm emailing the zipped package and opening it in another computer with an older macOS to test it. Can we make it compile for 64 by default? And what do I need to do to configure it to do so? thanks

1 0

CAF file support?
by Dan Wilcox 26 Apr '19

26 Apr '19

Howdy all, I am working on the 3rd iteration of a long term project we use for sound spatialization at ZKM. The current sound server was built using Pd and runs internally using libpd. We have many older projects which use CAF (Core Audio File) audio files (.caf or .caff) and I would need to be able to read them with Pd. I could find or make an external just for this file format, but I was thinking it could be generally useful to have this supported by [soundfiler], et al directly. CAF specification: https://developer.apple.com/library/archive/documentation/MusicAudio/Refere… <https://developer.apple.com/library/archive/documentation/MusicAudio/Refere…> The format is basically a container that takes different data formats, one being LPCM as in WAV & AIFF. We could post an error and ignore any compressed files. As the file structure is similar to WAV & AIFF, it seems like it wouldn't be too much work to add uncompressed CAF support to Pd and would work conceptually in the same manner. CAF files offer a couple of advantages: * 64-bit offsets for nigh-unrestricted durations (so file sizes > 4 GB) * recording could be faster as it allows for appending data * open format that is supported outside of macOS/iOS -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 12

[pure-data:bugs] #1317 float trims to int in expr
by Ticket #1317: float trims to int in expr 07 Apr '19

07 Apr '19

--- ** [bugs:#1317] float trims to int in expr** **Status:** open **Group:** v0.48 **Created:** Sun Apr 07, 2019 01:55 PM UTC by Anonymous **Last Updated:** Sun Apr 07, 2019 01:55 PM UTC **Owner:** nobody in a fresh install, i create the expr object with the argument '1.0'. upon losing focus, the '1.0' turns to a '1'. --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

Re: [PD-dev] translation push
by Dan Wilcox 05 Apr '19

05 Apr '19

(correct subject line) Ah, good point. Doing a string look up might not be the best thing, although maybe we can check performance metrics. It's not like there isn't string handling going on already and I doubt that gettext is doing allocations during a lookup. > On Sep 13, 2018, at 5:40 PM, pd-dev-request(a)lists.iem.at wrote: > > From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > > On 9/13/18 3:00 PM, Dan Wilcox wrote: >> For the developers, could we consider building Pd with gettext support in the core? Then we could translate most of the internal strings without having to resort to string matching on the GUI side. > > > what would be the benefit of that? > conceptually, i *quite* like the idea of not doing translation work in > the audio thread. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 3

Jump to page:

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