Pd-list February 2014

pd-list@lists.iem.at

94 participants
103 discussions

armonic properties of another sound
by flad chester 23 Feb '14

23 Feb '14

Hi, how can i give the armonic properties from one sound to another sound? I need to apply the armonic properties from a sound to another percusive sound that doesnt has a defined frequency ( noise) . Which is the best way of achieving this in pd? cheers F.

3 2

iem_sqrt4~ crashes on linux 6 bit
by Billy Stiltner 23 Feb '14

23 Feb '14

hey iem_qrt4~.pd_linux crashes the newest pd-extended as well as the latest pd source from sourceforge on ubuntu studio 13.04. I didn't want to mess with trying to figure out how to fix the source so I just made an iem_sqrt4~.pd that has a sqrt~ inside now all the iemlib vcf filters work . some of the vcf pd files had an iem_cot~ instead of iem_cot4~

1 0

Re: [PD] smooth random numbers
by Ingo 23 Feb '14

23 Feb '14

This one can be retriggered to change speed anytime. Ingo #N canvas 988 0 345 419 10; #X obj 71 135 random 128; #X obj 71 108 metro 5000; #X obj 71 90 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 189 line; #X obj 71 209 i; #X obj 71 162 pack f 5000; #X msg 254 32 5000; #X obj 161 384 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 365 5 0 0 0 - - -; #X obj 71 231 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 4400 1; #X floatatom 71 365 5 0 0 0 - - -; #X text 197 363 target; #X text 287 20 time; #X obj 14 73 loadbang; #X msg 253 10 1000; #X obj 181 69 t b f b; #X msg 134 19 0; #X msg 134 39 1; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 15 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 15 0; #X connect 15 0 17 0; #X connect 15 1 1 1; #X connect 15 1 5 1; #X connect 15 2 16 0; #X connect 16 0 2 0; #X connect 17 0 2 0; > -----Ursprüngliche Nachricht----- > Von: pd-list-bounces(a)iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag > von Ingo > Gesendet: Sonntag, 23. Februar 2014 04:21 > An: 'Roman Haefeli'; pd-list(a)iem.at > Betreff: Re: [PD] smooth random numbers > > Starting from Roman's patch I would probably do it like the attached > patch. > > Ingo > > > #N canvas 988 0 286 367 10; > #X obj 71 76 random 128; > #X obj 71 49 metro 5000; > #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; > #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg > 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 > 10 -262144 > -1 -1; > #X floatatom 161 306 5 0 0 0 - - -; > #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 > -1 -1 900 1; > #X floatatom 71 306 5 0 0 0 - - -; > #X text 197 304 target; > #X text 217 20 time; > #X obj 14 14 loadbang; > #X msg 183 10 1000; > #X connect 0 0 5 0; > #X connect 0 0 8 0; > #X connect 1 0 0 0; > #X connect 2 0 1 0; > #X connect 3 0 4 0; > #X connect 4 0 9 0; > #X connect 5 0 3 0; > #X connect 6 0 1 1; > #X connect 6 0 5 1; > #X connect 8 0 7 0; > #X connect 9 0 10 0; > #X connect 13 0 2 0; > #X connect 14 0 1 1; > #X connect 14 0 5 1; > > > > > -----Ursprüngliche Nachricht----- > > Von: pd-list-bounces(a)iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag > von > > Roman Haefeli > > Gesendet: Samstag, 22. Februar 2014 23:27 > > An: pd-list(a)iem.at > > Betreff: Re: [PD] smooth random numbers > > > > On Sam, 2014-02-22 at 21:54 +0000, Pagano, Patrick wrote: > > > > > > > > I would like to start creating random midi values from 0-127 and pick > > > each number say every 5 second and have each random number then flow > > > to the next smoothly. so if say the first number is 60 and the second > > > is 85, the data stream would flow from 60, 61, 62 63.....until it > > > reached 85 and then from 85 smoothly to the next random selection. > > > > See attached patch. > > > > > I have not had the luck i was hoping with Vline, someone suggested an > > > array but i am hoping someone might share some math or abstraction so > > > i can get a handle on how to implement it > > > > Though one could do it with [vline~ ], it is probably cheaper (cpu-wise) > > and actually simpler with [line]. The trick is to adjust the time grain > > to make it output only integer numbers. > > > > Roman > >

1 0

core <-> gui question
by Jonathan Wilkes 22 Feb '14

22 Feb '14

Hi list, I've got a nice little method for an info class in Pd-l2ork that tells whether an x/y coordinate lies within an object on a particular canvas. For the new svg-style drawing commands I've added, this method makes it possible to do some fairly simple tests within a patch to make sure I don't break things along the way. For example, I can check the bbox of scalars that contain transformed shapes, or check to make sure that the stroke-width is contained within the bbox, check positions of gop scalars, nested data structures, etc. If the gui and core were truly separated, how would I do these tests within Pd? To follow the Pd message-passing model, I need to get an answer to my query in zero logical time. If the bbox data is only held by the gui then I have to send a request over the socket, and the object chain will have finished computing before the gui sends back its data. If the core holds a synced copy of bbox data then the gui must either a) constantly bombard it with updated values or b) send a message that tells the core what got updated and let the core update data for all relevant objects. In which case there's no longer really a separation between gui and core. On a related note-- for the new drawing commands I'm doing all kinds of crazy calculations in the core for stuff like getting the bbox of an svg path. It's ridiculous because all that math has already happened in Tkpath, but I can cache it so Pd doesn't take a huge performance hit. But I simply couldn't figure out a way to get that data from the gui in a way that doesn't cause all kinds of syncronization problems. By the time *_getrect is called the core must already have the bbox data, otherwise it's too late. Is there some way to deal with that without moving the entire gui logic out of the core? I couldn't think of one. -Jonathan

1 0

ps3 controller under linux
by Atte 22 Feb '14

22 Feb '14

Hi I'm trying to get the input from a ps3 controller into PD. In the end I'd like to have it connect wireless, but for now I just connected via usb and tapped the PlayStation button on the controller. This shows up in lsusb: atte@skagen:~$ lsusb | grep Sony Bus 003 Device 013: ID 054c:0268 Sony Corp. Batoh Device / PlayStation 3 Controller "cat /dev/input/js0" (as regular user) show the expected garbage when moving the controller around or touching buttons. I also get input in chuck opened with Hid.openJoystick(0), so I'm pretty sure the controller is recognized and sending stuff into the system. In PD I trued using [hid] and sending [open XXXX( with just about everything I could think of. So I'm hoping someone could give a hint or suggestion about what to try next, things I could have forgotten etc. Regards -- Atte http://atte.dk http://modlys.dk

2 4

CUTE 2014 workshop, March 12-15, Mons, Belgium
by Miller Puckette 21 Feb '14

21 Feb '14

Hi all - THere's a free 4-day workshop March 12-15 in Mons, Belgium, given by Sebastien Rooy, Christophe d'Alessandro, Marc Leman, and me: http://checkthis.com/cute2014 (Marc and I will operate in Englich and Sebastien and Christophe in French). THere's a sign-up page here: https://www.eventbrite.com/e/cute-2014-tickets-10467012115 The workshop covers a wide range of topics of interest to computer musicians and computer music researcher. cheers Miller

1 0

t_scalar member sc_vec
by Jonathan Wilkes 21 Feb '14

21 Feb '14

Can anyone explain what's going on with this in m_pd.h: typedef struct _scalar /* a graphical object holding data */ { t_gobj sc_gobj; /* header for graphical object */ t_symbol *sc_template; /* template name (LATER replace with pointer) */ t_word sc_vec[1]; /* indeterminate-length array of words */ } t_scalar; How is a static t_word array of size 1 an indeterminate-length array? Is its placement as the last member of the struct required? I see lots of mysterious casts in the internals of Pd's data structures. What's the trick here, and is it documented anywhere on the interwebs, a C standard doc, etc.? Thanks, Jonathan

4 5

how can you know if [pix_fiducialtrack] tracks a shape or not?
by Alexandros Drymonitis 21 Feb '14

21 Feb '14

Once [pix_fiducialtrack] tracks a shape, you get a list which is the shape's ID, x/y coordinates and rotation angle. Once a certain shape has been tracked, how can you tell the difference between the shape being still and not being visible by the camera? Can you obtain any data for a shape appearing or disappearing from the camera?

1 0

Re: [PD] Game Audio abstractions- how to publish?
by Tony Hillerson 21 Feb '14

21 Feb '14

Filippo, you should put it up on Github. I can help if you need it... -- Tony Hillerson On Tuesday, February 18, 2014 at 22:07 PM, pd-list-request(a)iem.at wrote: > Send Pd-list mailing list submissions to > pd-list(a)iem.at (mailto:pd-list@iem.at) > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.puredata.info/listinfo/pd-list > or, via email, send a message with subject or body 'help' to > pd-list-request(a)iem.at (mailto:pd-list-request@iem.at) > > You can reach the person managing the list at > pd-list-owner(a)iem.at (mailto:pd-list-owner@iem.at) > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pd-list digest..." > > Today's Topics: > > 1. Re: Game Audio abstractions- how to publish? (Joe White) > 2. Re: Wich licence? (Mario Mey) > 3. Re: libpd separating gui from core (Rich E) > 4. Re: libpd separating gui from core (Jonathan Wilkes) > 5. Re: libpd separating gui from core (Jonathan Wilkes) > > Forwarded message: > > From: Joe White <white.joe4(a)gmail.com> > > To: Filippo Beck Peccoz <mail(a)fbpsound.com> > > Cc: PD list <pd-list(a)iem.at> > > Date: Tuesday, February 18, 2014 at 7:25:45 > > Subject: Re: [PD] Game Audio abstractions- how to publish? > > > > Nice one Filippo! Thanks for sharing > > > > Cheers, > > Joe > > > > > > > > On 16 February 2014 21:31, Filippo Beck Peccoz <mail(a)fbpsound.com (mailto:mail@fbpsound.com)> wrote: > > > Hello list, > > > > > > I've collected and cleaned up a few patches that I've been using a lot while making game audio with PD (mainly for Android, using libpd, Unity and Kalimba) and wanted to make them available to everyone. > > > Giving a tiny bit back since I've received so much help and advice from the PD community! > > > > > > I'm mainly trying to cover what a PD beginner/game audio composer would need in order to start building a PD-based audio engine for a video game. Threw in some mixer abstractions, some stuff for interactive music, a state-based drum machine and so on. > > > > > > As I said it's super basic, but it might just be less intimidating for someone who's just interested in the game audio potential of PD to have these basic blocks handy. > > > > > > Let me know if there is anything that can/should/must be improved in order for it to be of any use! I'd like to make help patches for the abstraction as well, but am not sure if they really need them since most of them are very simple. What do you think? > > > > > > https://fbpserver.dyndns.org/pydio/data/public/5b1c5c.php > > > > > > Cheers, > > > > > > > > > Filippo > > > > > > > > > > > > _______________________________________________ > > > Pd-list(a)iem.at (mailto:Pd-list@iem.at) mailing list > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > -- > > Follow me on Twitter @diplojocus > Forwarded message: > > From: Mario Mey <mariomey(a)gmail.com> > > To: pd-list(a)iem.at > > Date: Tuesday, February 18, 2014 at 12:54:03 > > Subject: Re: [PD] Wich licence? > > > > Right, I put GPL license, I think it is the best for this project. I > > uploaded it here: > > > > http://puredata.hurleur.com/viewtopic.php?pid=40358#p40358 > > > > You can see MEH-SYSTEM on stage and with full success, here: > > https://www.youtube.com/watch?v=ckKg_rS5ezQ > > > > Thanks everybody! > > > > > > > > On 16/02/14 02:03, Jonathan Wilkes wrote: > > > On 02/15/2014 03:14 PM, olm-e wrote: > > > > On 15/02/14 20:53, pd-list-request(a)iem.at (mailto:pd-list-request@iem.at) wrote: > > > > > Date: Sat, 15 Feb 2014 16:52:58 -0300 > > > > > From: Mario Mey <mariomey(a)gmail.com (mailto:mariomey@gmail.com)> > > > > > Subject: Re: [PD] Wich licence? > > > > > To: pd-list(a)iem.at (mailto:pd-list@iem.at) > > > > > Message-ID: <52FFC59A.4030401(a)gmail.com (mailto:52FFC59A.4030401@gmail.com)> > > > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > > > > > > > On 14/02/14 15:45, Jonathan Wilkes wrote: > > > > > > > How would that be any different than spyware? > > > > > > > > > > > > > > -Jonathan > > > > > Haha! Good point! > > > > > > > > > > Thanks everybody for the answers. I took a look to Matt Davey's DIY2 > > > > > effects and he put no license txt file on its folder. Maelstorm mmb > > > > > libraries have no license too... > > > > > > > > > > My patch is for everyone who wants to use it or learn with it. If > > > > > someone finally uses MEH-SYSTEM or a modified version of it in stage or > > > > > for a video or whatever... I "would like" to know it... only that! > > > > > > > > > > Maybe I leave it as is. Saying nothing about license... > > > > > > Skim the Wikipedia pages for GPL and 3-clause BSD, choose the one you > > > prefer, and then you're done. > > > > > > Otherwise you create potential work for anyone who may have a use for > > > your software to figure out what the terms of use and distribution > > > are. It's probably not a big deal for a particular piece of software, > > > and there are plenty of Pd patches out there that don't specify > > > anything. But when you take, say, everything that exists on Github, > > > the lack of licenses probably leads to busywork that eats up > > > measurable amounts of time and effort. > > > > > > -Jonathan > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > Hello, > > > > having no licence is probably not a good idea, as it's like enforcing > > > > the default copyright rules that basically give no rights at all ... > > > > (lots of code are practically not legaly usable on github for that > > > > reason f.ex.) > > > > the best would be IMHO to put it in (L)GPL and gently ask to downloaders > > > > to report use as a courtesy on the download page... > > > > have a good day, > > > > > > > > Ol. > > > > > > > > _______________________________________________ > > > > Pd-list(a)iem.at (mailto:Pd-list@iem.at) mailing list > > > > UNSUBSCRIBE and account-management -> > > > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > > > > > > _______________________________________________ > > > Pd-list(a)iem.at (mailto:Pd-list@iem.at) mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > Forwarded message: > > From: Rich E <reakinator(a)gmail.com> > > To: Dan Wilcox <danomatika(a)gmail.com> > > Cc: pd-list(a)iem.at List <pd-list(a)iem.at> > > Date: Tuesday, February 18, 2014 at 21:11:41 > > Subject: Re: [PD] libpd separating gui from core > > > > > > > > > > On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <danomatika(a)gmail.com (mailto:danomatika@gmail.com)> wrote: > > > Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right? > > > > > > On Jan 13, 2014, at 5:14 PM, Dan Wilcox <danomatika(a)gmail.com (mailto:danomatika@gmail.com)> wrote: > > > > Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving. > > > > > > IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned). > > > > > > cheers, > > Rich > > > Forwarded message: > > From: Jonathan Wilkes <jancsika(a)yahoo.com> > > To: pd-list(a)iem.at > > Date: Tuesday, February 18, 2014 at 21:23:01 > > Subject: Re: [PD] libpd separating gui from core > > > > On 02/18/2014 04:00 AM, IOhannes m zmoelnig wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > On 2014-02-17 22:42, Jonathan Wilkes wrote: > > > > No sane person is going to do incremental work without a plan on > > > > GUI software in 2014 that only has a single undo. > > > > > > > > > > luckily the work on the GUI will most likely happen in git, which > > > gives you infinite undo. > > > > > > > > > The question is whether a highly capable dev who isn't already > > entrenched in Pd development would see participation as worthwhile or a > > waste of time. > > > > What I'm saying is that without a clear plan, no sane developer is going > > to undertake the work of adding infinite undo, various GUI improvements, > > or anything else that can't ship as an external. > > > > But yes, technically you can use Git to do yet another GUI rewrite if > > you wish. > > > > -Jonathan > > > > > > > > fmasdr > > > IOhannes > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1 > > > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > > > > > iQIcBAEBCAAGBQJTAyE4AAoJELZQGcR/ejb4p20P/0v4ZnEhRhzuLBzl3Jr8bGRC > > > FSp04pTFlgdIqYPvJJooQA2vWJPHCOcHNPI7u8kDJk3tr+1p1EQ41apK6qFw/xU5 > > > E1093htLiZojq2OCMMO9ZOYbm0DXZZHRmo6nMcG2GXceqCSNA3OMw7p4MRGyVJB1 > > > tS/gyckHowInGDif+3eYKSD6iTZcBFpa/QahaT9kZzTk6HQ4hRtoro5OZ/z97nj6 > > > ILJsDv0xK01I4MF1s9OUsMdVp6itTCI9irHYOMr1IeNbhQMaZrT1z2HtqG9q8NZs > > > Q4p6uKGtGgqIZU5noCrmLnxVde0HlirpxSIDzq+FHJ4b9dQk9pJSI+zKTE8hCs1O > > > sCUFZNi2udd9NwkaAqs1/2msf15WO+GmguMZXzaOiOxcx9FKrVE03IATZ4vqLNCd > > > AucU9dxohcYrqPuzzBhfxmmYk6aLwPaZpamezTeBNCni0qn25X5ZwDWY6YHnd5fO > > > Ck1yvhWKO0g5jVH2Tx4iAgnceKVqe++q5q+XnR8goFPFvxPC3THCGoGaIx4FSgea > > > Zcfy3VymCWByyG57K2yV2R+wr3qwK8TDligtM0XoUB+a0caYr6uq5qMnOTzOJpIt > > > GpwrWerw1957a/ccxpkNpofh4HPosg0oeYRajc1mELY07bLcahgMaIGxIevxvub2 > > > 00RL1CEc36ySA5xLzcsd > > > =M/8o > > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > > Pd-list(a)iem.at (mailto:Pd-list@iem.at) mailing list > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > Forwarded message: > > From: Jonathan Wilkes <jancsika(a)yahoo.com> > > To: Rich E <reakinator(a)gmail.com>, Dan Wilcox <danomatika(a)gmail.com> > > Cc: pd-list(a)iem.at List <pd-list(a)iem.at> > > Date: Tuesday, February 18, 2014 at 22:07:20 > > Subject: Re: [PD] libpd separating gui from core > > > > On 02/18/2014 11:11 PM, Rich E wrote: > > > > > > > > > > > > On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <danomatika(a)gmail.com (mailto:danomatika@gmail.com)> wrote: > > > > Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right? > > > > > > > > On Jan 13, 2014, at 5:14 PM, Dan Wilcox <danomatika(a)gmail.com (mailto:danomatika@gmail.com)> wrote: > > > > > Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving. > > > > > > > > > IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned). > > You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime. > > > > Actually even in 2d without audio the problems manifest themselves pretty quickly. For example: open the svg tiger inside Inkscape and move it around. Notice the clever trick-- the image is broken into tiles and moved starting with the pieces closest to the mouse. Since the user's eye focuses on the mouse pointer, the interaction looks snappy even though it may take half a second or more to finish moving the tile furthest from the pointer. > > > > When you add realtime audio the options are either to err on the side of sluggishness or to be responsive and risk dropouts. If you want it to be responsive in both video and audio then you have to start doing some serious optimizations based on what you think the user cases are for the software. For example, the Inkscape trick is perfect for creating and manipulating vector graphics, but it would be terrible for a 2d animation environment where you'd presumably want the tiger to move as a single unit. > > > > However, many of Pd's current problems don't have a lot to do with that. Tk is pretty good at being sluggish and avoiding dropouts when it doesn't have idle time to do graphics updates. In fact I can move around an svg tiger on a canvas without interrupting the "test audio" patch. Most dropouts related to the GUI have to do with what amounts to a DDOS attack from the core to the GUI. When you flood tcl with data from the socket it can't really do anything else but spend time receiving it. When you add that to whatever Pd core is doing to generate all those messages in the first place, you probably won't have any time left over for delivering audio. > > > > Other toolkits are certainly more efficient than Tk. But if you're dragging an antialiased wire from the top left of the window to the bottom-right, the toolkit needs time to do those redraws. > > > > Finally, I'm not really sure how Open-GL and hardware acceleration plays into all this. For example, Qt Graphics View docs have a note about accelerated graphics possibly adding a performance hit and possibly more latency, but it's only in the context of hardware that doesn't do floating point computations efficiently. I played around with Kivy a bit, which is hardware accelerated but honestly didn't see much of an improvement in cpu usage over comparable stuff in Tkpath. > > > > -Jonathan > > > > > > > > > > > cheers, > > > Rich > > > > > > _______________________________________________ > Pd-list mailing list > Pd-list(a)iem.at (mailto:Pd-list@iem.at) > to manage your subscription (including un-subscription) see > http://lists.puredata.info/listinfo/pd-list > >

2 1

Re: [PD] Workshop on Audio Plug-Ins Design in Faust (Romain Michon)
by Bart Brouns 21 Feb '14

21 Feb '14

Hi, Faust is is a great complement to pd, as it makes light work of some things that are hard or impossible in pd, like good documentation, sharing programs, and 1 sample feedback loops. Will the course material be available online? Best, Bart. On Thu, 2014-02-20 at 12:00 +0100, pd-list-request(a)iem.at wrote: > Send Pd-list mailing list submissions to > pd-list(a)iem.at > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.puredata.info/listinfo/pd-list > or, via email, send a message with subject or body 'help' to > pd-list-request(a)iem.at > > You can reach the person managing the list at > pd-list-owner(a)iem.at > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pd-list digest..." > > > Today's Topics: > > 1. Workshop on Audio Plug-Ins Design in Faust (Romain Michon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 19 Feb 2014 09:33:17 -0800 > From: Romain Michon <rmichon(a)ccrma.stanford.edu> > Subject: [PD] Workshop on Audio Plug-Ins Design in Faust > To: pd-list(a)iem.at > Message-ID: > <CAOvVLsCn9dmOdr6bfpoRQrBSNRrqj39NFsU3XartuzD7RMrsqw(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Folks, > > I'll be giving a workshop on Audio Plug-Ins Design in Faust this summer at > the Center for Computer Research in Music and Acoustics (Stanford > University, USA) this summer (Mon, 07/07/2014 - Fri, 07/11/2014). > > Faust can be used to easily create PD externals so I thought that this > event might interest some of the members of this list. > > More informations are available on this page: > https://ccrma.stanford.edu/workshops/faust-workshop-2014 > > You can also contact me directly if you have specific questions: > rmichon(a)ccrma.stanford.edu > > Cheers, >

1 0

← Newer
1
2
3
4
5
6
7
8
...
11
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 February 2014