Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

Re: [PD-dev] dynamic patching - is iemguts the way to go?
by Alex Norman 21 Aug '19

21 Aug '19

Yeah, maybe that is positive (reverb tails etc) but if not, you could put the control on the other end, send your signal into every effect in parallel and then mix in the one you want to hear selectively. Alex On August 20, 2019 7:06:10 PM PDT, Nick Porcaro <nick(a)porcaro.org> wrote: >Hey x_nor, > >The problem with this approach is that you still have active signal >processing going in >each effect even if they are panned to zero (I assume) and you couldn’t >change the running >order of effect1 and effect2. > >Thanks for thinking on it though. I’m going to study Miller’s >responses and let you all know it goes- > >- Nick > >> On Aug 20, 2019, at 7:26 PM, x nor <x37v.alex(a)gmail.com> wrote: >> >> another approach could be to generate all the permutations of your >effects as abstractions and simply route audio to a permutation >selectively like you would with a speaker with an N-channel panner. >> >> [adc~] >> | [pan control] >> | | >> [pan~ ] >> | | .... >> [effect1~] | >> | [effect2~] >> | | >> [mixer~ ] >> | >> [dac~] >> >> >> generating abstraction by editing files as text is pretty simple, >patching each abstraction to a panner is probably pretty simple with >your text editor as well. >> >> though, maybe you don't have enough processing power for it? but.. >maybe you do? >> >> >> On Tue, Aug 20, 2019 at 4:09 PM Miller Puckette <msp(a)ucsd.edu ><mailto:msp@ucsd.edu>> wrote: >> actually I wrote that before I thought the whole thing out :) >> >> No, if you "tick" a pdlib instance you tick all the patches in it - >so teh >> way to get different patches in different orders is to call up a >separate >> Pd instance for each of them, and use "adc~" and "dac~" objects to >get >> audio in and out - that incurs zero latency (once you've buffered 64 >> samples in the first place). >> >> OR, within one pd instance, in libpd or in Pd, you can use switch~ >objects, >> switched off, to control each sub-patch. Send the switch~ objects >bangs in >> whatever orders you wish. In this scenario, tabsend~ and tabreceive~ >would >> be the simplemt way to pass signals between them. In libpd you can >do this >> zero-latency (just stuff your inpuits into arrays before sending all >the >> tick messages and copy the results out afterward). >> >> Within the Pd app, you can do teh same thing but you incur one tick >extra >> latency, because copying the autio into the tables has to happen on >the >> previous tick form the one on which you get the outputs back. >> >> If you like danger, you can write an external tilde object that, for >its >> "dsp" action, sends a message to teh patch that can "tick" the >switch~ >> objects right in the middle of Pd/s DSP tick. This is not part of Pd >> because it could cause major confusion if general-purpose Pd messages >> got sent around in mid-tick. >> >> cheers >> Miller >> >> On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote: >> > On Tue, 2019-08-20 at 12:09 -0700, Miller Puckette wrote: >> > > I think the way to do this in libpd is to open them all as >separate >> > > patches >> > > within one instance of Pd (so that symbols are shared) and use >> > > "tabsend" >> > > and "tabreceive" to route signals to/from them, using shared >names >> > > like >> > > "channel1" as both inputs and outputs so you can rearrange them >in >> > > any >> > > order. >> > > >> > > (Beware of allowing patches to _write_ andy of their output >channels >> > > before >> > > reading all the input channels, if you're re-using the same >channels >> > > as >> > > inputs and outputs :) >> > >> > Do I understand right: When loading them as separate patches, you >can >> > dynamically re-order the signal flow by using >[tabsend~]/[tabreceive~] >> > (which you could with abstractions, too) _without_ adding latency? >> > >> > And: When changing the symbol of [tabsend~] or [tabreceive~], is >the >> > DSP graph re-calculated? >> > >> > Roman >> >> >> >> > _______________________________________________ >> > Pd-dev mailing list >> > Pd-dev(a)lists.iem.at <mailto:Pd-dev@lists.iem.at> >> > https://lists.puredata.info/listinfo/pd-dev ><https://lists.puredata.info/listinfo/pd-dev> >> >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)lists.iem.at <mailto:Pd-dev@lists.iem.at> >> https://lists.puredata.info/listinfo/pd-dev ><https://lists.puredata.info/listinfo/pd-dev> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)lists.iem.at >> https://lists.puredata.info/listinfo/pd-dev

2 1

Re: [PD-dev] where is the search priority set?
by Dan Wilcox 20 Aug '19

20 Aug '19

> By working on Pd's manual, I can see the current priority is to look first > in the directory containing the patch, then in the search paths. I still > want to maintain that structure. I just think that the order of the paths > should be different, first with "standard paths" (which includes 'extra') > then the user added paths. I think you are right that the core "extra" externals should have priority. We've clearly de-emphasized users during everything into "extra" so, at this point, there shouldn't be much to break for people's setups. That's my macOS perspective. I suppose the situation might be a little different for some Linux packages? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 4

0.50-0 released (windows 64bit release with "font" troubles)
by Lucas Cordiviola 20 Aug '19

20 Aug '19

Hi Miller, The 64bit release has font troubles. Two files are missing: bin/pdfontloader.dll (the 64bit one) font/DejaVuSansMono-Bold.ttf (this one is the git repo and in is included in the 32bit release and is actually needed or we get an ugly render.) I attach "pdfontloader64.zip" ----------- To compile the 64bit pdfontloader.dll I did add these packages to MinGW with: pacman -S mingw64/mingw-w64-x86_64-tcl pacman -S mingw64/mingw-w64-x86_64-tk then I did "make" in pdfontloder dir. and rename the dll to pdfontloader64.dll. ---------- -- Mensaje telepatico asistido por maquinas.

1 0

pd 0.50-0 test1 on win64/tk64 and Pdfontloader
by Lucas Cordiviola 12 Aug '19

12 Aug '19

( writing this again as it was in a wrong thread and i have more info) I've detected that your "0.50-0 test1" for win64 is built with an 64-bit wish86.exe. This one does not ship, nor load the current pdfonloader.dll that it's for 32-bit only. I see 2 solutions: 1 - Build and use wish86.exe for 32bit. 2 - Build an 64bit "pdfontloader64.dll" and include some lines in pd-gui.tcl to auto-detect the current wish* architecture and then load the correct pdfontloader. ------------ As for solution 2 to I did: To compile an 64bit pdfontloader I did add these packages to MinGW with: pacman -S mingw64/mingw-w64-x86_64-tcl pacman -S mingw64/mingw-w64-x86_64-tk then I did "make" in pdfontloder dir. and rename the dll to pdfontloader64.dll. And included this lines in "pd-gui.tcl" (Line 407) : set arch $::tcl_platform(pointerSize) switch -- $arch { 4 { load [file join "$::sys_libdir" "bin/pdfontloader.dll"] } 8 { load [file join "$::sys_libdir" "bin/pdfontloader64.dll"] } } -- Mensaje telepatico asistido por maquinas.

1 0

icon files
by Dan Wilcox 12 Aug '19

12 Aug '19

Howdy all, As the icon refresh was integrated in Pd 0.49, should we consider bringing the master icon files (SVG and PNG export) into the main pure-data repo? I'm asking mainly as the question came up in relation to packaging for Arch Linux where the desire was to generate PNGs specific to the desktop environment form the SVG directly, however the master files are in my test/proposal repo: https://github.com/pure-data/pd-icon <https://github.com/pure-data/pd-icon> See discussion here: https://github.com/pure-data/pd-icon/issues/3 <https://github.com/pure-data/pd-icon/issues/3> I'd imagine simply adding an "icon" or "res/icon" directory for resources & assets and the masters + makefile there. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

where is the search priority set?
by Alexandre Torres Porres 10 Aug '19

10 Aug '19

Howdy, based on an issue I opened here https://github.com/pure-data/pure-data/issues/289 I'm trying to reset the search priority for loading objects and stuff. My motivation for this proposal/Pull Request is to have externals from the 'extra'; library have a priority over other externals. I was able to partially deal with this here: https://github.com/pure-data/pure-data/commit/d5296b3432a13a72f71bdf090e40a… But user added paths are still searched first. By working on Pd's manual, I can see the current priority is to look first in the directory containing the patch, then in the search paths. I still want to maintain that structure. I just think that the order of the paths should be different, first with "standard paths" (which includes 'extra') then the user added paths. Anyway, the thing is that I can't really find where I could change this search priority list... help? Oh, and if you think this shouldn't be done in the first place for any reason, just let me know :) thanks

1 0

[pure-data:bugs] #1318 download links are down. unable to download windows 64 bit Pure-data
by Ticket #1318: download links are down. unable to download windows 64 bit Pure-data 08 Aug '19

08 Aug '19

--- ** [bugs:#1318] download links are down. unable to download windows 64 bit Pure-data** **Status:** open **Group:** v0.48 **Created:** Thu Aug 08, 2019 02:55 AM UTC by Anonymous **Last Updated:** Thu Aug 08, 2019 02:55 AM UTC **Owner:** nobody download links are down. unable to download windows 64 bit Pure-data --- 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

[pdcontrol] reliance on Tcl
by Dan Wilcox 07 Aug '19

07 Aug '19

I'm just now looking into the new [pdcontrol] object and I like what I see. I am concerned about the gui sending feature as it seems to rely directly on Tcl. With my libpd hat on, I'm interested in moving the pd core towards less/no direct reliance on raw sending Tcl/Tk strings, basically making Pd more GUI agnostic. For the gui running Tcl/Tk, the plugin concept makes sense as it's focused on that domain and not with the pd core. However for a future libpd-based app that renders patches with a different framework on a specific platform (ie. PdParty) and focused on as much feature parity as possible, I may need to suddenly support people's edge-case usage of raw Tcl without a Tcl interpreter. If the idea is that gui sending provides a quick way to emulate a system() call, I can understand that however I think a more universal design would be based around system() itself and an overridable function or interface as some platforms, namely iOS, do not allow the use of system(). I bring this up now as once this precedent is set, it's obviously *very* difficult to change it once people start using this feature. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 4

Re: [PD-dev] can externals create data structures/templates?
by Dan Wilcox 06 Aug '19

06 Aug '19

I'd be nice to include this info in source comments somewhere... :) > On Aug 5, 2019, at 10:44 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Mon, 5 Aug 2019 22:39:26 +0200 > From: "Christof Ressi" <christof.ressi(a)gmx.at <mailto:christof.ressi@gmx.at>> > To: "x nor" <x37v.alex(a)gmail.com <mailto:x37v.alex@gmail.com>>, pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] can externals create data structures/templates? > Message-ID: > <trinity-77b48c6e-2e1c-4b37-9700-523e7c7d675d-1565037566616@3c-app-gmx-bs18> > > Content-Type: text/plain; charset=UTF-8 > >> is there documentation for what binbufs are and how they're used? > > I think you just have to read the source code in m_binbuf.c. But here's a general guide: > > Binbufs are containers for atoms. Unlike Pd lists, it can contain "special" atoms like A_SEMI or A_DOLLSYM. > > binbuf_text() converts a C string to a list of atoms. > bufbuf_gettext() converts the atoms back to a C string. > > binbuf_add() simply adds any kind of atoms to the binbuf > binbuf_getnatom() returns the size > binbuf_getvec() returns a pointer to the atoms. > > binbuf_addbinbuf() adds the content of another binbuf (possible containing "special" atoms) but bashes everything to A_FLOAT and A_SYMBOL > binbuf_restore() adds a list of atoms but restores "special" atoms from symbols, e.g. ";" -> A_SEMI, "\\$0-foo" -> A_DOLLSYM, etc. > > binbuf_eval() evaluates the stored binbuf by sending it as a message to the given target. > You can also pass an atom list as arguments, e.g. for a dollar symbols like "$1-foo". > "$0" is always substituted with the dollar zero of the current canvas (see canvas_getdollarzero, canvas_getcurrent and canvas_setcurrent). > Note that a A_SEMI atom will denote the start of a new message and the following atom will be taken as the new message target (must be a symbol). > > Here's an example (taken from x_text.c): > > a) The patch file: > > static char text_templatefile[] = "\ > canvas 0 0 458 153 10;\n\ > #X obj 43 31 struct text float x float y text t;\n\ > "; > > b) create a binbuf > > binbuf_text(b, text_templatefile, strlen(text_templatefile)); > > c) evaluate > > binbuf_eval(b, &pd_canvasmaker, 0, 0); > > Here's what happens: > > 1) "canvas 0 0 458 153 10;" goes to canvas maker -> create a new canvas, push it on the loading stack and bind #X to the canvas. > 2) the ";" terminates the messages and begins a new one. "#X" (= our canvas) will be the new target. > 3) "obj 43 31 struct text float x float y text t;" asks the canvas to create an object (like in dynamic patching) > 4) vmess(s__X.s_thing, gensym("pop"), "i", 0) sends the "pop" messages to the canvas. This effectively pops the canvas from the stack and #X is restored to whatever it has been bound before. > > Hope that helps. > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

can externals create data structures/templates?
by x nor 05 Aug '19

05 Aug '19

I'm starting to work with data structures and I'm curious if it is possible to write externals that generate structs/templates? Are there any examples of this? I guess I can do dynamic patching if not? Thanks!

2 4

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