Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
That is certainly true with bass (electric or upright) as well. (I'm watching this discussion with fascination!) Phil On 4/29/14, 12:10 PM, katja wrote: Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One
Re: [PD] Keeping Number box's
Or use the Number2 number box, and set its init attribute in properties. It will then init itself with the last value that was in the box at the time the parent patch was saved. On 4/14/14, 10:59 AM, AP Vague wrote: If you know exactly what you want the values to be before you open the patch you can replace the number atoms with messages, ie [32( instead of an atom. And then just send them a [loadbang] to initialize whatever they're going into... On Mon, Apr 14, 2014 at 1:47 PM, kate sweeney m.k.swee...@hotmail.com mailto:m.k.swee...@hotmail.com wrote: Hello, I am using GEM to create a graphical design video. I have completed a lot of it and have all my patches set up with the desired numbers etc. Yet everytime i close and re-open the project, all the numbers return to 0 which messes up my project big time. Is there a way to save the number box's as they are so they stay the same everytime the project is closed and re-opened? I have included a screenshot of before and after the project is closed and re-opened. Many thanks. ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keeping Number box's
oops, meant to send this to the list, sorry Jonathan. On 4/14/14, 1:11 PM, Phil Stone wrote: You have a point, if you are init'ing to zero; otherwise, it's easy to see that a Number2 box is init'd when you open the patch, because it has a non-zero value in it. But yeah, it's a little kludgey (especially the init/no init button: is it status, or what *will* happen when you press it -- hint, it's the latter, like most buttons). I wouldn't recommend it for use with all those Pd nuclear weapon-control patches that are out there. Phil On 4/14/14, 12:56 PM, Jonathan Wilkes wrote: On 04/14/2014 02:03 PM, Phil Stone wrote: Or use the Number2 number box, and set its init attribute in properties. It will then init itself with the last value that was in the box at the time the parent patch was saved. I try to avoid the iemgui init method because it isn't represented in the Pd diagram. I'd rather do this: [loadbang] [42( | [numbox] Then you can see if you made a mistake. For example, I forgot to connect [loadbang] to [42(. I can quickly scan all other places where I use [loadbang] to see if I made a similar error. But if you use the init method, you must right-click and choose Properties on every single numbox to do error checking. The time wasted isn't worth whatever it is you think you save by using init. Digression-- consider a Properties dialog with the following button: [don't fire nukes] Do you press it or not? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] It's too quiet in here
On 11/21/13 1:13 PM, Jonathan Wilkes wrote: On 11/21/2013 02:04 PM, Phil Stone wrote: Hmm, this once-thriving list has gone awfully silent of late. Is this thing on? tap tap I had the pleasure of meeting, for the first time, several august members of the Pd community this past weekend, thanks to Joe Deken and New Blankets gathering some of us together in San Diego and Los Angeles. Miller, Roman, Ivica, Jonathan, (and Katja -- I didn't do more than say hi, sorry) I just wanted to say that I am grateful to be involved in a group of such talented and humble people, and constantly marvel at what a powerful tool has been placed into my hands, at no cost. May Pd never die! Hi Phil, It was great to meet you! Personally I've been sending diffs to Ivica to get some stuff into Pd-l2ork, so that some of the features I showed in my workshop will work out of the box. Best, Jonathan I'm keeping a sharp eye on your work with Pd-l2ork on OS X, Jonathan. It looks like such an excellent environment, I really want to work in it. For one thing, I've heard all the many good arguments for straight, unsegmented patch cords, but I don't think I'd ever get tired of seeing splined patch cords in my patches! Having seen both, I'd say splines work better in all ways. BTW, regarding the title of this thread; I just searched the archives and realized that I hadn't gotten any messages since Nov. 6. After my post today, I'm getting them again. Anybody else had any glitches in getting list messages, or is it something local for me? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] It's too quiet in here
Hmm, this once-thriving list has gone awfully silent of late. Is this thing on? tap tap I had the pleasure of meeting, for the first time, several august members of the Pd community this past weekend, thanks to Joe Deken and New Blankets gathering some of us together in San Diego and Los Angeles. Miller, Roman, Ivica, Jonathan, (and Katja -- I didn't do more than say hi, sorry) I just wanted to say that I am grateful to be involved in a group of such talented and humble people, and constantly marvel at what a powerful tool has been placed into my hands, at no cost. May Pd never die! Respect, Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] It's too quiet in here
Hi Patrick, I'd like to say you're very welcome but I don't think that was me! :-) My only contribution to the Pd community is some (rather old and moldy at this point) polyphonic synthesizers on my web site. (www.pkstonemusic.com). Best, Phil On 11/21/13 11:24 AM, Pagano, Patrick wrote: Right on Phil, as I recall we web met via fractal midi software you wrote back in the day and you were kind enough to grant me - a starving gras student at that time a free license Sent from my iPhone On Nov 21, 2013, at 2:06 PM, Phil Stone pkst...@ucdavis.edu wrote: Hmm, this once-thriving list has gone awfully silent of late. Is this thing on? tap tap I had the pleasure of meeting, for the first time, several august members of the Pd community this past weekend, thanks to Joe Deken and New Blankets gathering some of us together in San Diego and Los Angeles. Miller, Roman, Ivica, Jonathan, (and Katja -- I didn't do more than say hi, sorry) I just wanted to say that I am grateful to be involved in a group of such talented and humble people, and constantly marvel at what a powerful tool has been placed into my hands, at no cost. May Pd never die! Respect, Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-l2ork running on OSX
I have too many prerequisite libraries to run completely successfully,
but what I can see is very impressive.
I think I'm almost immediately addicted to the splined patch cords. I'll
play with this some more when I finish my current project.
Nice work, Jonathan (and of course, Ivica et al. -- as an OSX user, I
haven't had the pleasure of seeing your work before today)!
Phil
On 10/24/13 9:02 PM, Jonathan Wilkes wrote:
Apropos:
Here's a first attempt at getting Pd-l2ork up and running on OSX:
https://jwilkes.nfshost.com/Pd-l2ork.app.zip
* Includes a few libraries: zexy, import, cyclone, and ggee
* I also replaced the help browser with the search-plugin powered by
the xapian backend
* I added references and meta patches to the control, audio, and data
structures tutorials.
If you haven't used Pd-l2ork before, it has some interesting features:
* infinite undo
* preset_hub and preset_node for settings presets on patches and
abstractions
* quick-connect: e.g., make a [route 0 1 2 3 4 5 6 7] and eight
message boxes below it, then select all of them and make a connection
from the leftmost outlet of [route] to the leftmost message box. Now
all are connected! (There are some other shortcuts when you select
just the topmost or bottommost object, too.)
* pdinfo, canvasinfo, and classinfo objects
* a bunch of other improvements that should all probably be documented
in a What's New patch that doesn't exist yet.
Please test it and let me know how it works.
If you'd like to give a donation, then please follow Joe's instructions
below for the New Blankets mini-fundraiser.
Best,
Jonathan
On 10/10/2013 12:48 AM, Joe Deken wrote:
New Blankets Inc. is a non-profit Foundation dedicated to the the
re-invention of the Free Community Public Library in the realms of new
media. Specifically New Blankets develops the dimensions _of_
-- free/open communities
-- _circulation_ and _sharing_ mechanisms
-- technology innovations
which together weave and support new benevolent cultural communities.
New Blankets is pleased to announce today the recognition of Jonathan
Wilkes as our latest Artist in Transit Fellow.
. New Blankets has provided Jonathan with an initial honorarium of
$500 to support his work.
. In addition to the initial honorarium support, New Blankets has
also launched a 1 : 1 matching mini-fundraiser during the
coming month (October 14 - November 14, 2013), to further support
Jonathan and the Artist-in-Transit Fellowship:
1) That is, any contributions to New Blankets during Oct 14 -
Nov 14
which you kindly care to make and designate for Artist in
Transit
will be matched 1 for 1 by New Blankets -- up to a $500
matching
limit.
2) At the end of the one month mini-fundraiser, the total sum
(your contributions + NB matching amount) will be
presented to
Jonathan at *PdWeekend* -- to be held Nov 15-17, 2013 with
Miller
Puckette Friends in San Diego and Los Angeles CA.
***
If you would like to make a contribution -- small or large --
to the
New Blankets Artist-in-Transit fundraiser, please send e-mail
ASAP to
New Blankets, using the special fundraiser address :
wilkes_...@newblankets.org
When we hear from you, we will arrange a convenient way for you to
send your check or electronic payment to New Blankets, by
whichever of
several available methods may be most convenient for you.)
***
** PdWeekend**
If you would like to participate in PdWeekend with us in
California on Nov 15-17, you are cordially invited and
most
welcome!
Kindly RSVP yes and let us know your plans to
participate
with us in San Diego (Nov 15) or Los Angeles (Nov 16-17)
by sending e-mail ASAP to:
pdweek...@newblankets.org
We will then send you a confirming e-mail immediately,
and we will keep you advised as our *PdWeekend* plans
and the details of events move forward, from now until
November 15.
The *PdWeekend* events are quite informal, but they also
will include four structured workshops on Saturday Nov 16
-- in co-operation with CrashSpace LA:
* Miller Puckette: Pd+Raspberry Pi
* Katja Vetter: DIY Live Sampling Microphone-Build
Slice//Jockey
* Ico Bukvic: Laptop Orchestrating with your Friends
* Jonathan Wilkes: Your Computer, Your Creativity
** Registration is required each of the above workshops **
Re: [PD] Preset saving with SSSAD
On 7/29/13 1:01 PM, Jonathan Wilkes wrote: In fact there are so many of the latter type of improvements that it's probably less work to port Pd-l2ork to Windows and OSX than it is to put those features back into Pd-Extended and Vanilla. If Pd-l2ork incorporated the 0.43 gui changes then that's probably what I'd spend my time doing. :) -Jonathan Speaking strictly selfishly, that would be a dream-come-true for me. I'd love to see the fork reunite, as it sounds like many excellent improvements have been made in Pd-l2ork that would be nice to have become mainstream. Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] direct connection from pd to webrowser, low latency
That's a fairly brilliant idea. No need for fancy audio-quality wireless units, either. Phil On 4/26/13 1:19 PM, Jonathan Wilkes wrote: From: katja katjavet...@gmail.com To: o...@onyx-ashanti.com onyxasha...@gmail.com Cc: pd-list Pd-list@iem.at; Martin Peach martin.pe...@sympatico.ca Sent: Friday, April 26, 2013 4:08 PM Subject: Re: [PD] direct connection from pd to webrowser, low latency Hi Onyx, What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system? I have a similar quest pending: to send Pd audio from a wearable computer over wireless to PA system. Why not send FUDI to a box connected directly to the PA system? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] wireless audio from Pd to PA system (katja)
These Line 6 units are well respected in the electric bass world, especially considering their moderate price. I think bass players appreciate tight timing, and the low lag may be one reason these units are popular. Also, they have proven to be rugged enough to be road-worthy. They can also model the hi-frequency lossiness of cords, though that seems of dubious value in your case. Phil On 3/1/13 12:24 PM, katja wrote: Apparently, Line 6 managed to build a digital 2.4 GHz wireless with 4 ms latency, the Relay G30, G50 etc . They do not write it in the specs, but most users don't notice latency and when they do, their support is speaking of latency as low as that: http://line6.com/support/thread/33898 This weekend I will do some WiFi experiments and see how fast it can go locally, using mrpeach udp and tcp classes. If it works, one could use a wireless router which has no other task than routing Pd audio, and the computer at the receiving end could be a cheap headless board with no other task than receiving Pd audio and converting it to analog. Together the receiving device could be the size of a weight-watcher's lunch box, while at the transmitter side the computer's built-in stuff is used. Maybe I'm a bit naive here, anyway I'll report results from experiments. Katja On Fri, Mar 1, 2013 at 2:14 PM, richard duckworth richduckwo...@yahoo.com mailto:richduckwo...@yahoo.com wrote: OMG - that's really high! Maybe Tranz have a belt holder solution - they do look kind of bulky though! Maybe worth dropping them a line, see if they'll help the Pd community Rich Duckworth Lecturer in Music Technology Department of Music House 5 Trinity College Dublin 2 Ireland Tel 353 1 896 1500 Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve *From:* katja katjavet...@gmail.com mailto:katjavet...@gmail.com *To:* Antoine Villeret antoine.ville...@gmail.com mailto:antoine.ville...@gmail.com *Cc:* richard duckworth richduckwo...@yahoo.com mailto:richduckwo...@yahoo.com; pd-list@iem.at mailto:pd-list@iem.at pd-list@iem.at mailto:pd-list@iem.at *Sent:* Friday, 1 March 2013, 13:12 *Subject:* Re: [PD] wireless audio from Pd to PA system (katja) Found more info about TI's PurePath wireless. Latency of wireless transmission is 768 samples minimum. Added to this must be the latencies of ad/da conversion. http://e2e.ti.com/support/low_power_rf/f/382/t/110331.aspx Forget about it, this concept is only useful for home entertainment. Katja On Fri, Mar 1, 2013 at 1:19 PM, katja katjavet...@gmail.com mailto:katjavet...@gmail.com wrote: Thanks everyone for your answers. The case is unconventional because a stereo line signal must be sent from the computer. Professional wireless systems assume mic or instrument. Consumer systems do transmit stereo signal, but without bothering too much about latency. Frankly, I did not expect the difficulty to find a good solution. Initially I wanted the wearable computer for a music video which is to be recorded live with sounds from natural objects. I bought the FM transmitter so my cameraman will be able to hear the music while he's filming. For this purpose it is ideal. Then I thought it would be good to use the computer in it's wearable mode for public performance. I figured that one of the many wireless solutions would suit the purpose, but didn't reckon with the unusual requirements. Further searching brought me to a new technology 'PurePath' from Texas Instruments. It has a range comparable with WiFi (30m), while it seems to work with paired devices as in Bluetooth. I haven't seen consumer products with this technology, but development kits are available. A rather convincing demo is here: http://www.youtube.com/watch?v=0YsnZQUfVGs If this system can work with low latency it could be perfect for wireless Pd. Katja On Fri, Mar 1, 2013 at 11:41 AM, Antoine Villeret antoine.ville...@gmail.com mailto:antoine.ville...@gmail.com wrote: hello, those are good for what they have been designed for and it depends on what you mean by exellent sound quality I've made few tests on those few years ago and the bandwidth could be good enough to transmit guitar/bass signal but nothing else for me + a -- do it yourself http://antoine.villeret.free.fr http://antoine.villeret.free.fr/ 2013/2/28 richard duckworth richduckwo...@yahoo.com
Re: [PD] [helmholtz~]
Hi Simon, I've been using [sigmund~] with pretty good results, tracking the bass and using it to drive various things in a complex Pd setup. I'm always interested in alternative pitch trackers, though. I play a Steinberger XL, so I won't likely be carving it up to put in a hex pickup; that's kept me a way from Roland's approach (that plus the cost!). I'm still quite intrigued by what you've done; do you have any documentation about it? Thanks for writing, Phil On 2/14/13 12:48 AM, Simon Iten wrote: hi phil, what are you trying to do? do you need midi from your electric bass? or just a way to make a synth in pd? i ask because i built a gr-300 emulation for bass that works very well and with almost no latency. you can drive any oscillator within pd from that. it's all signalpath though. ideally you would use such a thing with a hexaphonic (or quadraphonic) pickup, because it's monophonic. but the same is true for helmholtz i guess. cheers, simon On Feb 14, 2013, at 1:24 AM, Phil Stone pkst...@ucdavis.edu wrote: Hi Katja, I'm looking with great interest at your [helmholtz~] pitch tracking object. I'm not asking to be lazy (I'm going to try it out for myself!), but I'm wondering if you have any general impressions of its performance as to how it compares with [sigmund~]. I'm particularly interested as to how it will do for tracking a fretless electric bass. It looks like an excellent piece of work, and I've enjoyed reading your detailed page about it. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [helmholtz~]
Hi Katja, I'm looking with great interest at your [helmholtz~] pitch tracking object. I'm not asking to be lazy (I'm going to try it out for myself!), but I'm wondering if you have any general impressions of its performance as to how it compares with [sigmund~]. I'm particularly interested as to how it will do for tracking a fretless electric bass. It looks like an excellent piece of work, and I've enjoyed reading your detailed page about it. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi as rt guitar effect processor : proof of concept
Pierre, This is excellent news. I'm doing live processing of electric bass with desktop Pd, and have begun experimenting with the RPi. Your results are very encouraging. It's been a good couple of weeks for Pd on the Pi. Katja's de-normal detective work, the Pd-extended build, and Miller's ongoing work of course -- this is going to be exciting. I also like your home-brew foot gear. I did something similar with an Arduino mounted in an old Boss stereo foot pedal and some doorstop switches. Best, Phil On 1/28/13 9:38 AM, Pierre Massat wrote: Hi, My blog is here : http://guitarextended.wordpress.com/ I'll be writing a few posts to explain how it works, starting tonight. Cheers, Pierre. 2013/1/28 Oli Larkin olilar...@googlemail.com mailto:olilar...@googlemail.com very cool, awaiting the blog post! where's your blog? On 27 Jan 2013, at 16:00, Pierre Massat wrote: http://www.youtube.com/watch?v=NwJNeouLqgQfeature=youtu.be Dear all, It's working !!! :) It looks like a revolution to me. The effect in the second half is a sampler based on the phase-vocoder patch by Miller Puckette. I've set Pd to use a 16 ms buffer to get it to work without dropouts. It's a bit high but this is a demanding patch. I'll be documenting this on my blog, and i'd be glad to have feedback from you, about working/non-working audio interfaces for instance. Cheers! Pierre. ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pduino download?
Hi Hans, Is this still the right link for downloading Pduino? http://at.or.at/hans/pd/Pduino-0.5.zip It's currently timing out (found on this page: http://puredata.info/downloads/pduino/releases/0.5). thanks, Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] share-mem lib
Cyrille, this is very exciting. Where can we get more details? Phil On 10/31/12 4:19 PM, Cyrille Henry wrote: hello, i just did a initial commit of share-mem, a lib dedicated to deal with shared memory. background : pd / pd~ communication is really slow. by example, having a pd~ patch with 8 audio in and 8 out, use about 50% cpu of a recent computer for each process only to deal with audio communication. sending a large array from one process to the other is almost not possible in RT. This really limit pd~ usability. - Thanks to share memory, communication between process can be greatly improve. This lib is mainly composed of an external, and few abstraction and examples. Everything look stable, at least on a ubuntu (12.04) and a osX laptop. Implementation follow POSIX standard, so it will unfortunately not work on windows. everything that I need is there, even if lot's more work could be made. I hope to have user feedback before making more development. Cheers Cyrille ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] creation parameters to inlets/outlets for documentation?
One potentially nasty drawback to this practice (I found) was that if you change the pseudo-argument in any way, you lose whatever connections were made to that inlet or outlet in the outer patch. I agree with you that comments are a pain in the neck, but at least they don't exhibit this often hard-to-find side effect. Phil www.pkstonemusic.com On 6/19/12 12:41 PM, Jörn Nettingsmeier wrote: quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects? i'd like to do something like this: [inlet Set level in dB] [inlet Set Fader position in mm] [outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient] of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste... best, jörn ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] creation parameters to inlets/outlets for documentation?
I should clarify this by adding that the side-effect won't happen if you edit an abstraction's inlets/outlets without any objects that include that abstraction being open at the time. Apparently, the change causes a re-instantiation of the abstraction in the parent, breaking the inlet/outlet connections. On 6/19/12 1:22 PM, Phil Stone wrote: One potentially nasty drawback to this practice (I found) was that if you change the pseudo-argument in any way, you lose whatever connections were made to that inlet or outlet in the outer patch. I agree with you that comments are a pain in the neck, but at least they don't exhibit this often hard-to-find side effect. Phil www.pkstonemusic.com On 6/19/12 12:41 PM, Jörn Nettingsmeier wrote: quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects? i'd like to do something like this: [inlet Set level in dB] [inlet Set Fader position in mm] [outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient] of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste... best, jörn ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
On 2/26/12 10:29 AM, Mathieu Bouchard wrote: Le 2012-02-25 à 14:29:00, Phil Stone a écrit : IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The edit/play dichotomy, The Edit/Play modes are there just to allow more different mouse commands. It's not really a feature of the engine, it's just for switching between two sets of mouse behaviours in the GUI, because there are not enough buttons. That's a good point, but the other problem I mentioned -- audio dropouts during editing, especially if the dsp graph needs recompiling -- is still a deal breaker for live *performance* coding (unless one embraces the glitches). Now, if by 'live', one just means highly interactive, I'll grant Pd that. That's more what I'm concerned with anyway -- a rapid connection between idea and execution, not necessarily doing programming in front of an audience. I also like programming in word languages, For what I presume you call a non-word language, Pd has quite a large vocabulary of words in it. I'm pretty sure you, and most readers of this list, understand the distinction I am making between graphics-dominated and text-dominated programming environments. Perhaps the scare quotes should be a tip that I'm not speaking in exactitudes at that moment. :-) Don't think that your points about the liveness of Pd are lost on me, though. I've been thinking about it a great deal since watching that video yesterday, and realized the very interactiveness the guy in the video was bragging about is something we take for granted. Number boxes change values instantly! Wow! I was excited, however, by the capability of changing underlying code by manipulating the product. Pd even nudges into that territory with its bastard son dynamic patching, but it's not particularly intuitive. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
On 2/25/12 11:43 AM, Mathieu Bouchard wrote: Le 2012-02-25 à 12:32:00, patrick a écrit : I wish I could code an external like he's coding: http://vimeo.com/36579366 you're not mentioning which part of this extremely long video you are referring to, and this player does not allow skip-ahead, which means I can't fast-forward faster than the download speed of the whole thing. This is why I won't try to figure out what you mean. It's well worth watching, all the way through. It was a eureka moment for me -- I now see the potential of live-coding. Phil __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
On 2/25/12 1:20 PM, Mathieu Bouchard wrote: Le 2012-02-25 à 13:14:00, Phil Stone a écrit : It's well worth watching, all the way through. It was a eureka moment for me -- I now see the potential of live-coding. Ah ok, you mean that you didn't see the potential of live-coding by using PureData ? But PureData isn't just about the potential of live-coding. It's also about doing it. Possibly even every time you use it. IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The edit/play dichotomy, and the probability of audio dropouts resulting from trying to use both modes simultaneously is a big obstacle to smooth live-coding. I use Pd because it is the best compromise that I have found toward achieving this idea-implementation feedback loop for audio/music design. I still maintain a divide between my design phase and my performance phase, though; I'd love to see that divide fade away. I also like programming in word languages, and a Supercollider-type language with this the one in this video's level of instantaneous, round-trip synchronization between code and product would be pretty great. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
On 2/25/12 2:49 PM, Hans-Christoph Steiner wrote: On Feb 25, 2012, at 4:14 PM, Phil Stone wrote: On 2/25/12 11:43 AM, Mathieu Bouchard wrote: Le 2012-02-25 à 12:32:00, patrick a écrit : I wish I could code an external like he's coding: http://vimeo.com/36579366 you're not mentioning which part of this extremely long video you are referring to, and this player does not allow skip-ahead, which means I can't fast-forward faster than the download speed of the whole thing. This is why I won't try to figure out what you mean. It's well worth watching, all the way through. It was a eureka moment for me -- I now see the potential of live-coding. I agree that instant feedback is very important, that's a big reason why I use Pd. I wonder if he's ever used Pd. Pd has been providing a lot of that experience for almost 2 decades now. The one thing in it that Pd does not provide is the ability to click on the generated image in order to see which code is generating that part of the image. That would be a nice feature to have. But I can't see how you would generalize beyond drawing pictures. Drawing with code is basically the easiest realm to solve that particular problem, IMHO. How would you click on the sound to see the code that is generating it? How would you click on a mail program, a network service, file encryption? Visual representations of audio/music parameters are quite common (spectral plots, traditional and non-traditional notation, spatial controls, etc.). Having a two-way connection between graphical representations of audio/music and the underlying code would be quite useful and conducive to empirical experimentation. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pop-up menu, drop-down select box
I can't remember ever seeing add-ons for PD for widgets like pop-up menus or drop-down select boxes. Has anyone done any tcl experimenting in this area? The closest widget I can think of is Sevy's Playlist; as cool as it is, it doesn't have the screen real-estate economy of a pop-up or drop-down. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pop-up menu, drop-down select box
Thank you, Jonathan. [tof/pmenu] does exactly what I need. Phil On 2/12/12 9:49 PM, Jonathan Wilkes wrote: I used my search plugin to search for gui menu and found one: tof/pmenu There is also [popup] which looks like it's now in the library flatgui (which used to be flatspace). -Jonathan - Original Message - From: Phil Stonepkst...@ucdavis.edu To: PD listpd-list@iem.at Cc: Sent: Monday, February 13, 2012 12:19 AM Subject: [PD] pop-up menu, drop-down select box I can't remember ever seeing add-ons for PD for widgets like pop-up menus or drop-down select boxes. Has anyone done any tcl experimenting in this area? The closest widget I can think of is Sevy's Playlist; as cool as it is, it doesn't have the screen real-estate economy of a pop-up or drop-down. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to tidy up patches ? (?????? ????????)
On 1/11/12 6:12 PM, Alexandre Torres Porres wrote: is there any option in PD to make complex patches look less messy ? not really. What you have to do is be able to design the patches with method, and think about it. I personally don't see this as a restrain, or something serious we should worry about in doing it. I can easily get lost when MAX's chords are not just a straight line explicitly telling you where it's coming from and going to. And hiding chords or patch bits can be a lot like throwing the mess under the carpet. A code in order to be really clean and tidy needs to be well organized, rewritten, and just clear. So, all you got is subpatches and send objects. Just do hundreds of subpatches, it can be really good for making you have to think about designing an organized patch, it may be better than being allowed to, lets say, cheat and pretend is not messy. but that's me... cheers alex No, it's me, too, and many other PD-coders, I'm sure. Excellent advice, Alex. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] using PD/GEM to generate timecode overlay
On 11/3/11 7:37 AM, Mathieu Bouchard wrote: Symbols are never freed, so, it's better to use several separate [text2d] to reduce the total number of symbols created. Otherwise, as tens of thousands of symbols are created, not only it takes RAM, but it also slows down the symbol table (this means it slows down any uses of gensym). Good point, Mathieu. Attached is a stopwatch I made a few years ago that practices symbol conservation. It could easily be modified to do timecode. Phil Stone pkstonemusic.com #N canvas 651 43 543 587 10; #X obj 0 1 cnv 15 150 30 empty empty empty 20 12 0 14 -228856 -66577 0; #X obj 41 2 cnv 15 12 28 empty \$0-hour_colon : 0 13 0 24 -1 -241291 0; #X obj 82 2 cnv 15 12 28 empty \$0-minute_colon : 0 13 0 24 -1 -241291 0; #X obj 2 2 cnv 15 14 28 empty empty empty 0 15 0 24 -1 -241291 0; #X obj 163 7 loadbang; #X obj 11 125 f 0; #X msg 98 527 label \$1; #X obj 98 548 s \$0-hours; #X msg 263 527 label \$1; #X obj 263 548 s \$0-minutes; #X msg 453 527 label \$1; #X obj 453 548 s \$0-seconds; #X obj 10 258 f 0; #X obj 10 284 mod 60; #X obj 10 340 f 0; #X obj 40 340 + 1; #X obj 10 361 mod 60; #X obj 10 316 select 0; #X obj 10 446 f 0; #X obj 40 446 + 1; #X obj 10 390 select 0; #X obj 10 467 mod 99; #X obj 10 490 makefilename %2d; #X msg 47 125 0; #X obj 176 29 r \$0-reset; #X msg 130 202 0; #X obj 10 232 spigot 0; #X msg 78 184 0; #X obj 11 185 t b a; #X msg 11 208 1; #X obj 261 346 symbol 0; #X obj 257 255 spigot 0; #X obj 163 54 t b b b b b b; #X msg 313 227 0; #X msg 283 227 1; #X obj 236 228 sel 1; #X text 278 53 seconds between restarts; #X obj 383 306 s \$0-r-onoff; #X msg 383 281 color \$1 0; #X msg 383 257 13; #X msg 413 257 16; #X obj 10 37 r \$0-onoff; #X obj 77 124 sel 0; #X obj 10 60 t f f f; #X obj 10 85 s \$0-color; #X obj 383 210 r \$0-color; #X obj 383 233 sel 0 1; #X text 35 206 skip 1st bang; #X obj 114 319 makefilename %02d; #X obj 53 2 cnv 15 30 28 empty \$0-minutes -- 2 15 0 24 -1 -241291 0; #X obj 95 2 cnv 15 54 28 empty \$0-seconds -- 2 15 0 24 -1 -241291 0; #X obj 3 18 bng 10 250 50 0 \$0-reset empty empty 17 7 0 10 -262144 -1 -1; #X obj 128 8 tgl 17 0 \$0-onoff \$0-r-onoff empty 17 7 0 10 -258699 -1 -262144 0 1; #N canvas 0 22 336 383 resetDisplay 0; #X obj 31 25 inlet; #X msg 30 308 label \$1; #X obj 30 335 s \$0-hours; #X msg 101 308 label \$1; #X obj 101 335 s \$0-minutes; #X msg 182 308 label \$1; #X obj 182 335 s \$0-seconds; #X obj 30 67 symbol --; #X obj 101 66 symbol --; #X msg 174 204 label \$1; #X msg 185 134 label \$1; #X obj 185 161 s \$0-hour_colon; #X obj 174 231 s \$0-minute_colon; #X obj 172 65 symbol :; #X connect 0 0 8 0; #X connect 0 0 7 0; #X connect 0 0 13 0; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 5 0 6 0; #X connect 7 0 1 0; #X connect 8 0 5 0; #X connect 8 0 3 0; #X connect 9 0 12 0; #X connect 10 0 11 0; #X connect 13 0 10 0; #X connect 13 0 9 0; #X restore 160 167 pd resetDisplay; #X msg 165 527 label \$1; #X obj 165 548 s \$0-hour_colon; #X msg 343 527 label \$1; #X obj 164 504 symbol :; #X obj 341 424 symbol :; #X obj 343 548 s \$0-minute_colon; #X obj 10 415 t a b; #X msg 416 424 0; #X obj 257 279 t b b b b; #X obj 416 453 makefilename %02d; #X obj 88 389 makefilename %02d; #X obj 14 2 cnv 15 27 28 empty \$0-hours -- 0 15 0 24 -1 -241291 0 ; #X obj 40 258 + 1; #X obj 11 166 metro 1000; #X text 265 16 - wraps to zero at 100 hours; #X text 265 39 - doesn't remember partial; #X text 265 75 - doesn't leak symbol table memory; #X connect 4 0 32 0; #X connect 5 0 35 0; #X connect 5 0 67 0; #X connect 6 0 7 0; #X connect 8 0 9 0; #X connect 10 0 11 0; #X connect 12 0 13 0; #X connect 13 0 17 0; #X connect 13 0 48 0; #X connect 13 0 66 0; #X connect 14 0 16 0; #X connect 15 0 14 1; #X connect 16 0 15 0; #X connect 16 0 20 0; #X connect 16 0 64 0; #X connect 17 0 14 0; #X connect 18 0 21 0; #X connect 19 0 18 1; #X connect 20 0 60 0; #X connect 21 0 19 0; #X connect 21 0 22 0; #X connect 22 0 6 0; #X connect 23 0 67 0; #X connect 24 0 32 0; #X connect 25 0 15 0; #X connect 25 0 19 0; #X connect 25 0 66 0; #X connect 26 0 12 0; #X connect 27 0 26 1; #X connect 28 0 29 0; #X connect 28 1 26 0; #X connect 29 0 26 1; #X connect 30 0 6 0; #X connect 30 0 8 0; #X connect 30 0 54 0; #X connect 31 0 62 0; #X connect 32 0 5 0; #X connect 32 1 25 0; #X connect 32 2 53 0; #X connect 32 3 27 0; #X connect 32 4 34 0; #X connect 32 5 23 0; #X connect 33 0 31 1; #X connect 34 0 31 1; #X connect 35 0 31 0; #X connect 38 0 37 0; #X connect 39 0 38 0; #X connect 40 0 38 0; #X connect 41 0 43 0; #X connect 42 0 27 0; #X connect 43 0 44 0; #X connect 43 1 42 0; #X connect 43 2 5 0; #X connect 45 0 46 0; #X connect 46 0 39 0; #X connect 46 1 40 0; #X connect 48 0 10 0; #X connect 54 0 55 0; #X connect 56 0 59 0; #X connect 57 0 54 0; #X connect 58 0 56 0; #X connect 60 0 18 0; #X connect 60 1 57 0; #X connect 61 0 63 0; #X connect 62 0 33 0; #X connect 62 1 30 0; #X connect 62 2 58 0; #X connect 62 3 61 0; #X connect 63 0 10 0; #X connect
Re: [PD] [PD-announce] PD (audio+code)--“eetz” new EP @ FIBRR RECORDS [NOISH]
Oskoff, This is a formidable and beautiful piece... Phil On 4/20/11 9:55 AM, oskoff lovich wrote: Hi all a new audio+code release salut! -- --- *chaos audio teorie – extrange attractors–[from mathematical functions to organic jungle sounds]* - EP: one track 25 minutes + code (pure data) Release generated from the heretical use and the experimentation with the sonic possibilities of the iterative function “logistics” in a “complex number” versión [real+imaginary]. Inspirated but desviated from the research and work by “Elaine A. Walker” http://www.ziaspace.com/elaine/chaos/ChaosMelodyTheory.pdf f(xn+1) = 1 – rxn2 adding chaos to the chaos jumping from attractor to attractor eternal instability 3d Fractals modulate the temporal frequency of the iterations (Chaos PD external by Ben Bogart) Audio generators : I used [polywavesynth] a polyphonic synthesizer for Pure Data by Phil Stone http://www.pkstonemusic.com/polyWaveSynth.html and some other more simple oscilator, [nqsint] + FM-AM . After record some audio blocks using the code included. I edited and mixed them into Ardour. software : Pure Data + Ardour Linux: Ubuntu Karmic Koala ::: Download Audio VBR MP3 31mb http://www.archive.org/download/eetz_noish/eetz_noish.mp3 Download Audio WAV 256.6 mb http://www.archive.org/download/eetz_noish/yupana_c_a_t_noish.wav Download CODE (pureData) http://noconventions.mobi/noish/download/yupana_Exploit_cat.zip *:::* FIBRR RECORDS http://www.apo33.org/records/doku.php?id=virtual_records noish [oscar martin] http://noconventions.mobi/noish *:::* -- mEtaminaFreeNetRadio http://metaminafnr.hotglue.me/ http://noconventions.mobi/noish ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI triggered samples
Hi Jaime, Thanks for the suggestion, and for further clarifying (in my mind) what I'll need. I think readsf~ won't do because of the open before play requirement -- it will introduce latency and prevent re-triggering, if I'm not mistaken. I guess it's going to be a matter of loading as many tables in memory as I can get away with and using tabread4~ with a phasor. Thanks for writing, Phil On 3/24/11 11:37 PM, Jaime Oliver wrote: Hi Phil, if they'll always play from the beginning and the only control you need is amplitude, then I would try readsf~. J On Thu, Mar 24, 2011 at 1:57 PM, Phil Stonepkst...@ucdavis.edu wrote: OK, this was probably too broad a way to pose this. Let me try it this way: I'm not concerned with looping, re-sampling or sample-rate changing. I simply want a low-latency trigger of a sound file from an incoming event. The file(s) may, however, be quite large. So, is a phasor-scanned [tabread4~] the best way to go about this? Will memory management become an issue if I have 44 or 88 of these large samples in memory at once? thanks, Phil On 3/24/11 11:30 AM, Phil Stone wrote: Hello collective PD mind, Despite having worked with PD for years, I've never used it as a sample player. I have a project coming up where I will need to build a bank of MIDI-keyboard-triggered samples to play in real-time, with velocity sensitivity and one sample per key. Rather than reinvent the wheel, is there something someone has already done along this line? If not, can anyone give me a basic outline from which I can start? Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI triggered samples
How did I miss this one? Thanks, William, [tabplay~] indeed looks promising. And thanks for the cool example, Jose. Phil On 3/25/11 3:22 PM, William Brent wrote: Sounds like there's no shortage of options here, but since you don't have to do any transposing, [tabplay~] is useful and just as low latency as a [phasor~] + [tabread4~]. It's great for long files because you don't have to worry about bit precision for the index. On Fri, Mar 25, 2011 at 6:09 PM, Jose Luis Santorcuato santorcuat...@gmail.com wrote: Hi Phil, the promised... my patch for work with korg padkontrol, easy to use, and very simple. Best José 2011/3/25 Charles Goyardc...@fsck.fr Hi Phil, Phil Stone wrote: Thanks for the suggestion, and for further clarifying (in my mind) what I'll need. I think readsf~ won't do because of the open before play requirement -- it will introduce latency and prevent re-triggering, if I'm not mistaken. It seems that readsfv~ from moonlib could do the job: it does direct-from-disk reading. I tried with a 650MB wav file with no perceptible latency. Plus keep in mind that once a file has been read, it can stay for some time in the system disk caches. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://arselectronicachile.blogspot.com http://comunicacionnativa.blogspot.com/ http://www.myspace.com/santorcuato ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] MIDI triggered samples
Hello collective PD mind, Despite having worked with PD for years, I've never used it as a sample player. I have a project coming up where I will need to build a bank of MIDI-keyboard-triggered samples to play in real-time, with velocity sensitivity and one sample per key. Rather than reinvent the wheel, is there something someone has already done along this line? If not, can anyone give me a basic outline from which I can start? Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI triggered samples
OK, this was probably too broad a way to pose this. Let me try it this way: I'm not concerned with looping, re-sampling or sample-rate changing. I simply want a low-latency trigger of a sound file from an incoming event. The file(s) may, however, be quite large. So, is a phasor-scanned [tabread4~] the best way to go about this? Will memory management become an issue if I have 44 or 88 of these large samples in memory at once? thanks, Phil On 3/24/11 11:30 AM, Phil Stone wrote: Hello collective PD mind, Despite having worked with PD for years, I've never used it as a sample player. I have a project coming up where I will need to build a bank of MIDI-keyboard-triggered samples to play in real-time, with velocity sensitivity and one sample per key. Rather than reinvent the wheel, is there something someone has already done along this line? If not, can anyone give me a basic outline from which I can start? Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Polyphony and granular synthesis, etc.
Peter, You are correct that [poly] imposes a MIDI-like structure in that it works with note/velocity pairs. I just wanted to point out that it does not clip those tuplets in a MIDI way; i.e., you can pass floats for both note and velocity to your polyphonic instrument. Your general point is still taken, that a more generalized, perhaps list-passing [poly] would be very useful. BTW, I've made a granular-based polyphonic synthesizer for Pd; it's here: http://www.pkstonemusic.com/polygrainsynth.html , along with it's older sibling a subtractive/fm hybrid polyphonic synthesizer: http://www.pkstonemusic.com/polywavesynth.html . Phil Stone On 3/10/11 9:25 AM, Peter Kirn wrote: Hi everyone, I'm revisiting granular patches as I work on some examples for libpd. Any kind of granular synthesis is, of course, heavily dependent on polyphony. That raises the question of how to instantiate multiple copies of the same abstraction. The issue is, many non-external methods of doing this right now depend on poly, which in turn assumes MIDI parameters. I would prefer something that uses arbitrary parameter lists. We actually could now do this two ways: 1. We can instantiate multiple patches when opening them in libpd, maintaining independent references to each patch, as Peter Brinkmann recently described on his blog - http://bit.ly/egBGV2 2. Perhaps there's a way to do this using an abstraction? nqpoly, etc., I believe did this, but it seems it's not supported - and may not be the best approach? Thanks, Peter PETER KIRN | http://createdigitalmusic.com | ny, ny | pe...@createdigitalmedia.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music made with PD
Very nice! Have you discussed the Zin here before? If not, what is going on there? Phil Stone www.pkstonemusic.com On 3/1/11 8:15 AM, Eduardo Patricio wrote: Hello, list! Two more videos: http://vimeo.com/20464262 - Wii stuff + Pd http://vimeo.com/20464964 - Zin (arduino based) + Pd Cheers Eduardo _ Eduardo Patrício http://www.eduardopatricio.com.br +55 41 8434-0480 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Need Help Understanding pack
Happens to me all the time -- I have to point when I'm a passenger giving directions to a driver -- I usually say the wrong one first. I thought it was because I'm left-handed (or slightly brain-damaged). Phil On 2/9/11 1:16 AM, Frank Barknecht wrote: On Wed, Feb 09, 2011 at 08:52:50AM +0100, Frank Barknecht wrote: Again, left-alignement helps thinking about and reading patches. See the subpatch for a solution without pipe - and without triggers as well. [trigger] is important, but only when objects don't have enough outlets themselves. [unpack 0 0 0] already has three outlets that, just like [t f f f] fire from left to right, so triggering explicitly is not needed. Oops. Please invert: just like [t f f f] fires from right to left. 71 of 364 (19.5%) college professors and 311 of 1185 (26.2%) college students said that they occasionally, frequently or all of the time had difficulty when they had to quickly identify right from left. References: 1. Brandt, J. and Mackavey, W. Left-right confusion and the perception of bilateral symmetry. International Journal of Neuroscience, 12:87-94, 1981. 2. Hannay, H.J., Ciaccia, P.J., Kerr, J.W. and Barrett, D. Self-report of right-left confusion in college men and women. Perceptual and Motor Skills, 70:451-457, 1990. 3. Harris, L.J., Gitterman, S.R. University professors' self-descriptions of left-right confusability: sex and handedness differences. Perceptual and Motor Skills, 47:819-823, 1978. http://faculty.washington.edu/chudler/java/hands1.html Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Maybe I'm pushing dynamic object creation too far
Ed, I don't know if anecdotal confirmation will help you here, or just make you more frustrated, but I've noticed that I get more dropouts using Jack as opposed to portaudio (OS X) for the exact same processor-load. This has caused me to switch back to portaudio. Does anybody have any idea why this might be? Phil Stone www.pkstonemusic.com On 2/2/11 3:25 PM, Ed Kelly wrote: On 2011-02-02 01:00, Ed Kelly wrote: I get dropouts, regardless of the jack buffer size/buffers number. Is this because the dynamic creation of a new object interrupts the pd audio stream? If so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it) and 2. if so, can pd -nogui sort it out? the problem most likely comes from the DSP graph being continuously rebuilt. the only things you can do for now is: - - try to reduce rebuilding of the DSP graph as much as possible. needeless to say that you shouldn't dynamically create objects that are not needed. more interesting is that e.g. creating 3 objects while audio is running, will re-caculate the DSP graph 3 times. even if this happens in 0 logical time. so i you know you are going to schedule several dynamically created objects at once, turn audio off before and turn it on again after you do the actual creation. Dammit! Only one at a time, but they are tables of perhaps 30 points. Then I copy data from the input buffer into the table. It has to be running with the audio, since the audio is being re-mixed in real time. Everything works fine if I'm using the onboard sound - e.g. OSS, but the problems only happen when I switch to jack. Of course the onboard sound would be OK if I was using only output, but the whole point is to live-sample the input. The mic input on my laptop is really crappy. - - try to get the DSP graph building into a separate thread. well, this involves pd~ or the like Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM - but I see the new version of Inscore supports PD, so all my work over the last 6 months has been for nothing. Pah! Ed fgmasdr IOhannes [1] btw, it's usually really easy to check things: e.g. running your patch with -nogui and see whether you get dropouts might take about the same time as (you) asking on this list, (me) answering on this list and (you) reading the answer - not counting the delay due to amil-servers and the like. anyhow. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1JKCQACgkQkX2Xpv6ydvQzfQCgsvmL0cevgXGPbL1oZW4keMcu diwAoJaN6Pvheh261jAZwzr2CpJ78ypV =z/KF -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Am I alone?
On 1/29/11 12:16 PM, Josh Moore wrote: Well in my opinion most electroacoustic shit is all surrealist/dadaist crap. The people involved try too hard to be the electronic version of John Cage, it's quite annoying. In fact, I'm so against it that I'm going to come up with a parody album with actual good dance music that uses elements of the academic code geek norm with real electronic music that have titles like computer scientists make for very bad musicians and chainsaw in a cave, recorded 6 feet down Rest of polemic deleted for brevity's sake You're certainly going way out on a limb with that position -- I mean, how brave of you to take up the mantle of champion for poor, defenseless good dance music. If it weren't for experimentalists, the tools used by pop musicians to make good dance music wouldn't exist in the first place. If you don't like the compositions made by experimentalists, don't listen to them, but you haven't come up with a compelling argument for the innate superiority of the music you happen to find enjoyable, merely a rather juvenile list of pejoratives for that which doesn't happen to appeal to your taste. By the way, it is considered bad nettiquette to cross-post to several lists like this. I have limited my reply to one list. Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 200 voices of timbre-space navigation
Really, really great, Hans! I'm having a lot of fun with this, and look forward to digging into it to figure out how it works... Phil On 11/22/10 9:47 AM, Hans-Christoph Steiner wrote: I was just working on a library of objects for creating and managing many instances. In the process I created a couple examples to play with: - ticker.pd, a 100 voice clock ticker, make it tick very fast! - run-200voicestest.pd, a 200 voice sample stretcher and panner These are based on voicepoly/voicepolywrap, which aims to be an easy-to-use replacement for nqpoly4. You can drop voicepoly.pd and voicepolywrap.pd into your path (http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files ) and then use it from anywhere without having to copy it into your project. http://at.or.at/hans/pd/play/200voices.zip Hopefully you have as much as I did making it! .hc If you are not part of the solution, you are part of the problem. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Snow Leopard 64-bit: Pd-0.42.5-extended-rc3 not found
Hi Hans, I figured I'd try the 64-bit build for Snow Leopard, but it's 404'ing from link on the PD Installers page. Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.42.5 release candidate 2 released!
On 6/11/10 2:25 PM, Hans-Christoph Steiner wrote: Of course we missed somethings, so now we have 0.42.5-rc2! Hi Hans, Most things look good so far, (macbook pro intel 10.6). Any idea what all the canvas_coords insert mucho whitespace here messages cluttering up my console are? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd?
There is little doubt that dance music dominates popular music, and has done so for eternity, but it certainly does not encompass all that is good music. Just because you feel the urge to move your body to music that is not dance-centric, i.e., you rock to Beethoven, or Liszt, or Charlie Parker, that does not mean music should be judged by its ability to draw people on to the dance floor. That really describes a rather small slice of good music. Nor, I think, should it be the metric by which Pd is judged -- certainly not Pd's Hello World -- unless Pd is defined as a programming language for electronic dance music. Also, I think there has been some f'ing excellent dance music made with Pd, so I don't really understand the complaint in the first place. Phil Jonathan Wilkes wrote: --- On Thu, 4/15/10, Phil Stone pkst...@ucdavis.edu wrote: From: Phil Stone pkst...@ucdavis.edu Subject: Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd? To: PD list pd-list@iem.at Date: Thursday, April 15, 2010, 7:49 PM In addition to disagreeing vehemently with your main point (Pd is good for little more than experimentation), I find this a piss-poor acid test for music that sounds good: colet.patr...@free.fr wrote: there is no such project that show how pd is cool to make people moving on the dance floor. Phil- I dig music with compelling sounds, and I generally feel the urge to move my body to music I dig. One can use whatever test one wants to hold up some music as genuine, and the question does it draw people out onto the dance floor? is just as valid as any other in this regard. But then if the point of the acid test is to demonstrate the strengths of a visual programming paradigm for the rapid implementation of various dsp techniques to generate music, I'd say the OP's test is quite a fitting and effective Hello World for Pd. -Jonathan Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd?
In addition to disagreeing vehemently with your main point (Pd is good for little more than experimentation), I find this a piss-poor acid test for music that sounds good: colet.patr...@free.fr wrote: there is no such project that show how pd is cool to make people moving on the dance floor. Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] any mac OS terminal experts?
Strike that; I see you were talking about the [shell] external, not bash. That'll teach me to post before getting coffee in. Phil Phil Stone wrote: Andy Farnell wrote: On Sat, 27 Mar 2010 11:22:20 -0400 Michal Seta m...@artengine.ca wrote: in MacOS, however, it always reports the root of the system. If ever there was a nasty accident waiting to happen this takes the cake :) Except it isn't true, at least as far as I can tell from a quick check of the shell. pwd reports the current directory, at least interactively. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] any mac OS terminal experts?
Andy Farnell wrote: On Sat, 27 Mar 2010 11:22:20 -0400 Michal Seta m...@artengine.ca wrote: in MacOS, however, it always reports the root of the system. If ever there was a nasty accident waiting to happen this takes the cake :) Except it isn't true, at least as far as I can tell from a quick check of the shell. pwd reports the current directory, at least interactively. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Hello!
Welcome, Josh. I'll also put in a plug here for my synthesizer based on Jamie Bullock's granular synthesis engine: http://www.pkstonemusic.com/polygrainsynth.html Phil Derek Holzer wrote: Hi Josh, welcome on board! I also went from Reaktor (and Audio Mulch) to Pd, but that was many years ago in the dark ages when I used woolly mammoths on a treadmill to power my laptop, and cavebear bones as a physical interface. If you're into granular stuff, have a look at my Particlechamber abstraction: http://macumbista.net/?page_id=514 Due for an update after 7 long years sometime this spring or summer ;-) Best, Derek Josh Moore wrote: It's great fun, more stable than Reaktor which I think is yuck to begin with, and I'm mostly learning for the lack of good live granular synthesis on the mac. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD with SnowLeopard
I was having a similar problem, but eventually noticed that the freeze-ups happened only after wake from sleep. With sleep disabled (not a good long-term solution, I realize), Pd-extended (v. 0.41.4) runs rock-stable. I halfway suspect it is my M-Audio Ozone drivers that is not recovering from sleep, but I haven't tested to isolate that yet. Phil Stone http://www.pkstonemusic.com Morgan Evans-Weiler wrote: Is anybody having problems running Pd extended with Snow Leopard? I'm having trouble getting it running correctly without it freezing up. It will work fine for a few minutes but soon freezes and will not let me open or close files or open or close the program. I would appreciate any help. Thanks Morgan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD with SnowLeopard
A follow-up: I now strongly suspect that it is the M-Audio Ozone driver for Snow Leopard that is freezing on sleep. I tried sleeping my Pd-extended setup without the keyboard connected (i.e. using the MacBook's internal sound out), and there was no sleep-freeze. I did have to turn audio off and then on again after waking before sound would be produced, however. Phil Phil Stone wrote: I was having a similar problem, but eventually noticed that the freeze-ups happened only after wake from sleep. With sleep disabled (not a good long-term solution, I realize), Pd-extended (v. 0.41.4) runs rock-stable. I halfway suspect it is my M-Audio Ozone drivers that is not recovering from sleep, but I haven't tested to isolate that yet. Phil Stone http://www.pkstonemusic.com Morgan Evans-Weiler wrote: Is anybody having problems running Pd extended with Snow Leopard? I'm having trouble getting it running correctly without it freezing up. It will work fine for a few minutes but soon freezes and will not let me open or close files or open or close the program. I would appreciate any help. Thanks Morgan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Roman Haefeli wrote: This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already. Hi Roman, I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, and it's annoying to more experienced programmers. I want to address the point you brought up in the first message: $0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list. But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2 in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument repeated over and over as justification for its prohibition in message boxes? I just don't understand this. If only (as many have said) $0 had been written as #0 or something else completely un-encumbered with ideas about what $ must mean in Pd. The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? Well, I think that would make things even worse - further muddying the waters, as it were, by adding yet another meaning to the dollar-sign. I don't see it as any more consistent or pure, given the unique role that $0 has in *all* cases. When all is said and done, things in the Pd world will go on as they have, and we won't really suffer because of this one little grain of sand in our shell. But we probably will continue to discuss it every few months! Best, Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
IOhannes m zmoelnig wrote: Phil Stone wrote: I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, i agree and it's annoying to more experienced programmers. but i can't follow here .-) Well, I'm annoyed. :-) But I think I'll get over it. But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2 in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument actually i do. obviously it would break everything, so i won't say that loud. snip as explained lengthily months ago, i still don't think that messages should have any notion of the surrounding patch. I'd be interested in reading that, though I haven't been able to find the post yet. Do you have a reference? Currently, the only time I've needed to get $0 into a message is for dynamic patching. Since this practice is an unloved bastard child of Pd, it's unlikely I'll get anywhere advocating for making it easier. Nevertheless, the less-readable patches (as if dynamic patches aren't obscure enough!) that result from the contortions needed to get $0 into the message annoy me, and tempt me to write bad, name-clash-ripe dynamic objects. Best, Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Roman Haefeli wrote: While definitely understanding your irritation, the only point of your writing i was able to find is that it would make it 'easier'. No, it's that the idea of $0 = special case is only used when talking about message boxes; $0 is also a special case in object boxes, yet it is accepted there. Thus, I find this argument inconsistent. I am quite willing to bear the continued burden of coaxing $0 into messages for dynamic patching (I simply have no choice). I would just like to see the reasoning against $0 in message boxes be less specious, and therefore less confusing to the overall issue. I definitely cannot support the idea of making one special case (that arises a lot, i admit) easier, while disregarding completely the concepts and consistency. As I said, it's the very *inconsistency* of this argument that bothers me. Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Matt Barber wrote: I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. Good points, all. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion not be on auto-repeat here. Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Roman Haefeli wrote: Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different. Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic. roman Actually, all it would take to convert all old patches to this new form is one line of perl with a well-constructed regular expression. I agree, still, that it is probably not going to happen. Phil On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote: Matt Barber wrote: I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. Good points, all. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Mathieu Bouchard wrote: On Fri, 13 Nov 2009, Frank Barknecht wrote: Alexandre Porres hat gesagt: // Alexandre Porres wrote: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different. That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different. $3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero it's a special case no matter what. Right. Which neatly brings the question back around to why can't $0 be used in message boxes? I've said this before (to no avail): it is well understood that $0 has no meaning in *messages* -- however, this is not a good reason why $0 can't be used in *message boxes.* Since 1024-foo (where 1024 represents the canvas-identifier), *does* have meaning in messages, why must we jump through (admittedly minor, but still quite annoying) hoops just to get that canvas-identifier into a message? It probably belongs in the some things will never change in Pd category; therefore we must resign ourselves to this discussion re-appearing on a regular basis. Phil Stone http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] OS X 10.6
Hello, Has anyone had any luck compiling Pd-Extended for Snow Leopard? Is it close to showing up in the nightly builds? I ask because I may have to switch to 10.6 soon. Thanks, Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very small form-factor PC for running PD
Aside from the 12v capability, I'd have said the Mac Mini...if you're into that sort of thing. Phil Stone Hans-Christoph Steiner wrote: You could use a Nokia N810 for that. It does have USB, but not powered, so you'd need to include a powered hub. Beagleboard is another option: http://beagleboard.org/ .hc On Oct 22, 2009, at 7:16 PM, Martin Dupras wrote: For a project I'm working on, I need a very small computer capable or running PD in an enclosure ideally smaller than 20cmx15cm. It doesn't need to have a screen, but it needs to have at least two USB ports and be able to be run on 12v DC or lower. Has anyone come across anything like this? Cheers, - martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Feedback discussion
Of course, feedback does not require simultaneity...nor does it always imply an acoustic system (though I'm guessing that's what you're referring to, Derek). One nice thing about those digital goblins is that they can feed-back *information* about the music. More interestingly, they can feed-back *permuted* information about the music, kind of like a delay line with ideas of its own. Phil Stone www.pkstonemusic.com Derek Holzer wrote: I can't really say from a supra-atomic standpoint I could agree with you, but I'd settle for the speed of light, or even the remotely distant figure of the response time of an op-amp. Which is quite a bit faster than your average blocksize or even a single discrete sample--assuming that a complex digital system like Pd could react effectively at single-sample speed. Really though, must everything really be so complicated Mathieu? Not everything can be so easily described with mathematics. I also like to sip single malt whiskey during the last evening hours of a summer headed towards autumn... Sorry to stir up the digital goblins, folks. I merely wanted to share my (unsatisfactory) experiences with feedback scenarios in Pd. Your Mileage May Vary. D. Mathieu Bouchard wrote: Instantaneousness is a myth. It does not exist in nature. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] implications of pd~ for 'poly' objects
Thanks for clarifying that, Hans, and for pointing out the issue with threads, IOhannes. One shouldn't be profligate with [pd~]s, strewing them all about and expecting performance gains -- therefore, one [pd~] per voice instance in a [polypoly] patch is probably not a good idea until we have 64-core CPUs as a regular thing! :-). However, with judicious use, [pd~] seems like it will allow Pd to scale to future processor design, and that's a good thing. Thanks again, Phil Hans-Christoph Steiner wrote: [snip] As for manually managing pd~, I mean just manually creating as many pd~ instances as you have cores. .hc IOhannes m zmoelnig wrote: Phil Stone wrote: Hi Hans, Thanks for replying. I don't quite understand what you mean by manually manage. As far as I know, without something like [pd~], there's no way to divide up and assign the Pd audio process to more than one core. Half of the cores on a quad-core are therefore useless to Pd (accounting for the fact that the graphical process gets its own core). the problem is, that poly-class objects are usually meant for _many_ objects (10+; i'm only repeating here what hans has already said). [pd~] will fork a new thread for each of it's instances. when doing multi-core processing (and this is really the only thing pd~ is good for; e.g .it's not good if you want to have different priorities / asynchronous processing), you usually don't want to create more threads than you have cores. why? performance reasons! if you create e.g. 1000 threads for 1000 instances of [doodle~] on a quad-core machine, your computer will spend more time handling context-switches and the like (that is: the overhead for managing the threads) than doing the actual job. as a rule of thumb, the optimum number of threads is about the number of cores you want to use. since what is sold to customers as multi-core processors usually does not involve more than 4 cores, the best (though probably not the most comfortable) way to assign work to the cores from within Pd is doing it manually fmgasdr.# IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] implications of pd~ for 'poly' objects
Hello all, I have skimmed Miller's paper from Pd-con about [pd~], and it looks like it has potential for taking advantage of multiple-core CPUs. I need to read it in a little more detail to digest it fully, but I'm wondering (and this is directed mostly at Frank B.): could [polypoly] and/or [nqpoly] use [pd~] for each voice/replicated-patch instance? Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] implications of pd~ for 'poly' objects
Hi Hans, Thanks for replying. I don't quite understand what you mean by manually manage. As far as I know, without something like [pd~], there's no way to divide up and assign the Pd audio process to more than one core. Half of the cores on a quad-core are therefore useless to Pd (accounting for the fact that the graphical process gets its own core). Phil Hans-Christoph Steiner wrote: It would definitely be possible to write a pdpoly~ but usually it would be easier to manually manage 2-4 instances. Few people have more than 4 cores. I see those poly objects as useful for 10+ and make managing 100s or 1000s possible. .hc On Sep 8, 2009, at 1:24 PM, Phil Stone wrote: Hello all, I have skimmed Miller's paper from Pd-con about [pd~], and it looks like it has potential for taking advantage of multiple-core CPUs. I need to read it in a little more detail to digest it fully, but I'm wondering (and this is directed mostly at Frank B.): could [polypoly] and/or [nqpoly] use [pd~] for each voice/replicated-patch instance? Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] another dynamic patching question
Hi again, I'm happily creating subpatches and filling them with dynamic subpatches (thanks again, Jonathan), but now I'm stuck on something more subtle. I'm doing something like this: [b] | [symbol G] | [; pd-exp-$1 msg 20 235 /analysis/level/$1; ( to dynamically add a [/analysis/level/G ( message box to subpatch 'exp-G'. However, what I really want that message box to say is: [/analysis/level/G $1( so I can do something useful with that message. How do I get '$1' into that message box, dynamically? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] another dynamic patching question
Brilliant hack, Jack - thanks a million! Thanks for your suggestion, too, dmotd. Phil Jack wrote: Hello Phil, See the patch attached ++ Jack Le mercredi 02 septembre 2009 à 22:09 -0700, Phil Stone a écrit : Hi again, I'm happily creating subpatches and filling them with dynamic subpatches (thanks again, Jonathan), but now I'm stuck on something more subtle. I'm doing something like this: [b] | [symbol G] | [; pd-exp-$1 msg 20 235 /analysis/level/$1; ( to dynamically add a [/analysis/level/G ( message box to subpatch 'exp-G'. However, what I really want that message box to say is: [/analysis/level/G $1( so I can do something useful with that message. How do I get '$1' into that message box, dynamically? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] dynamic subpatch creation
Hello all, I'm playing with dynamic object creation, and so far have figured out how to dynamically instantiate objects inside a subpatch and connect them up. Now I'm trying to dynamically create subpatches inside of that subpatch, and I thought I could do this by sending canvas/ restore... messages to the subpatch in the appropriate order. When I try this, I crash Pd. Now, it may be that I'm not forming the messages correctly, but before I wander down that potentially-primrose path of debugging, I'm wondering if what I'm doing is possible at all. This is the message I'm trying to send when Pd crashes ($1 contains the subpatch's name -- I know this is correct from earlier experiments that didn't use canvas/restore): ; $1 canvas 5 5 362 348 f_instance 0; $1 obj 29 86 routeOSC /name; $1 obj 29 111 routeOSC /f /q; $1 obj 22 160 bp~; $1 obj 22 195 *~ 0.0002; $1 obj 22 224 env~ 8192; $1 obj 22 252 int; $1 msg 22 278 /fout/lev/name pd-1010-dfb; $1 connect 1 0 6 0; $1 connect 2 0 4 0; $1 connect 4 0 5 0; $1 connect 5 0 6 1; $1 connect 5 1 6 2; $1 connect 6 0 7 0; $1 connect 7 0 8 0; $1 connect 8 0 9 0; $1 connect 9 0 10 0; $1 connect 10 0 3 0; $1 restore 127 223 pd f_instance; So, is it the canvas/restore messages that are crashing Pd, and if so, is there some other way to dynamically created subpatches inside another subpatch? Thanks for reading, Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamic subpatch creation
Thanks, Jonathan. That's just what I needed. Phil Jonathan Wilkes wrote: If you dynamically created a subpatch named my_subpatch, then to dynamically create a subpatch within that use: [obj 0 0 pd nested_subpatch( | [s pd-my_subpatch] -Jonathan --- On Thu, 9/3/09, Phil Stone pkst...@ucdavis.edu wrote: From: Phil Stone pkst...@ucdavis.edu Subject: [PD] dynamic subpatch creation To: PD list pd-list@iem.at Date: Thursday, September 3, 2009, 1:01 AM Hello all, I'm playing with dynamic object creation, and so far have figured out how to dynamically instantiate objects inside a subpatch and connect them up. Now I'm trying to dynamically create subpatches inside of that subpatch, and I thought I could do this by sending canvas/ restore... messages to the subpatch in the appropriate order. When I try this, I crash Pd. Now, it may be that I'm not forming the messages correctly, but before I wander down that potentially-primrose path of debugging, I'm wondering if what I'm doing is possible at all. This is the message I'm trying to send when Pd crashes ($1 contains the subpatch's name -- I know this is correct from earlier experiments that didn't use canvas/restore): ; $1 canvas 5 5 362 348 f_instance 0; $1 obj 29 86 routeOSC /name; $1 obj 29 111 routeOSC /f /q; $1 obj 22 160 bp~; $1 obj 22 195 *~ 0.0002; $1 obj 22 224 env~ 8192; $1 obj 22 252 int; $1 msg 22 278 /fout/lev/name pd-1010-dfb; $1 connect 1 0 6 0; $1 connect 2 0 4 0; $1 connect 4 0 5 0; $1 connect 5 0 6 1; $1 connect 5 1 6 2; $1 connect 6 0 7 0; $1 connect 7 0 8 0; $1 connect 8 0 9 0; $1 connect 9 0 10 0; $1 connect 10 0 3 0; $1 restore 127 223 pd f_instance; So, is it the canvas/restore messages that are crashing Pd, and if so, is there some other way to dynamically created subpatches inside another subpatch? Thanks for reading, Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Hot inlet position
Hi Gabriel, Projects need excellent criticism; they become moribund without it. Matju's understanding of Pd is deep and broad, and he's not just making noise -- the things of which he speaks are always interesting to me, because they give insight into the inner workings of Pd. It's easy to hear hostility in this text medium, when in reality it's probably just passion. Phil Gabriel Vinazza wrote: I don't think Pd is an instrument, not in the sense you seem to understand something is it. It seems you don't have much to do or your job is not so exciting like fixing your deficiencies by spiting those horrible arguments to people that have more noble objectives. You can hear yourself now, I won't reply. On Thu, Aug 20, 2009 at 4:22 PM, Mathieu Bouchardma...@artengine.ca wrote: On Thu, 20 Aug 2009, Gabriel Vinazza wrote: Once more, as an artist, I know that the freedom is on my mind... so I can make music even with a spoon. Spoons are a traditional percussion instrument in my culture. The idea that music can be made with a spoon is thus not only normal to me, it's also very old-fashioned. I just wanted to say that Pd is a beatiful spoon. I hope that it can be used as much more than that. I mean, there are all those sophisticated devices that in the end got used as doorstops and paperweights, and I don't wish them that. I justed want to say that Pd is an excellent kind of Pd (sic), that can be used in terms of what it is instead of whatever else we like to compare it to. (comparisons also become more legitimate when you carefully select the object compared to, according to the number and depth of its similarities...) And if ideally Pd should be just a musical instrument that you only have to tune and play, it's only to go with those musicians who ideally should understand the breadth and depth of Pd's potential, but in practice don't. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] metastudio 3 CRITICAL update
I'm sorry if I missed it in an earlier thread, Ed, but what is this svf_f1~ that you speak of? I've been using svf~ (many instances at once, in fact) for a couple of years without crashes, though sometimes the CPU climbs a bit when no sound is being made -- but again, no crashes. Phil Stone pkstonemusic.com Ed Kelly wrote: Hi all, I've updated the metastudio packages with the old svf~ external in the drumsynths (clinok~, clinoker~ and fmf_perc~) and svf_fl~. The bsaylor/svf~ external has problems - denormals cause the filter to max out the CPU and will crash any patch mid-preformance. I also found this problem with moog~ (in moog_fl~) so watch out for it crashing your patch! If it does, I recommend switching to svf_fl~ for a dynamic filter. This is a critical update, so if you're using metastudio then head over to http://sharktracks.co.uk/puredata And save yourself some future embarrassment! Enjoy! Ed ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] HID problem in Xubuntu.
I have a similar, but slightly different, problem on OS X (10.4, Macbook pro). A Logitech Marble Mouse (trackball) shows up as device 0, but I can't get any data out of it. The trackpad, on the other hand, is fully accessible through [hid]. Any ideas? Phil Hans-Christoph Steiner wrote: Chances are that the trackpad is an USB device, but just internal. But I don't think that's the issue. I think in recent versions of Ubuntu, the X server or related process grabs the keyboard and mice using exclusive access. You have to tell the X server to not use the mice that you want to use with [hid]. Check the archives, there is quite a bit of discussion about it. It would be great to have a wiki page about this... .hc On Jul 15, 2009, at 12:26 PM, Diego Azar wrote: Hi Simon, Thanks for the fast response. No, it isn't. It's the standard synaptic touchpad that comes with many laptops. Diego. --- On *Wed, 7/15/09, Simon Wise /simonzw...@gmail.com mailto:simonzw...@gmail.com/* wrote: From: Simon Wise simonzw...@gmail.com mailto:simonzw...@gmail.com Subject: Re: [PD] HID problem in Xubuntu. To: Diego Azar dazar...@yahoo.com mailto:dazar...@yahoo.com Cc: PD-List pd-list@iem.at mailto:pd-list@iem.at Date: Wednesday, July 15, 2009, 11:14 AM Diego Azar wrote: Hi, I'm trying to use de hid librari in Xubuntu. I installed pd-hid.deb package without trouble and everything works perfect (usb mouse, keyboard, etc) except for the touchpad. It's not a permission issue, i've already gave permission to /dev/input/event0-9 and /dev/input/mouse0-2. is your touchpad a USB HID device? Simon ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] xapian search engine for Pd
Hi Hans, I'm a little unclear, would this replace the find function on the find menu? If so, that would be wonderful; the current find has a serious drawback in that it can't find partial object names, neither can it find names containing $0; these two attributes combine to make it impossible to track down objects named similarly to '$0-foo'. I understand the issue with $0, being that it is replaced with a generated number, but partial-string search would be a fantastic improvement. Phil Hans-Christoph Steiner wrote: Hey, I've been thinking for a while that Pd really needs a good built-in search function. I just found this Xapian search library that has good Tcl bindings, anyone ever used it? I suppose it could also be implemented in C in 'pd' rather than in Tcl in 'pd-gui'. It seems like a pd-gui thing tho. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.41.4 release candidate 1
Mac OS X 10.4 i386. Cannot reproduce. Phil brandon zeeb wrote: Mac OS X 10.5 i386. Has anyone else been seeing this? On Thu, May 14, 2009 at 10:52 AM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.at wrote: Hey, Let's keep these on list please. That's an odd one, I use that all the time on Mac OS X and Ubuntu. Which platform are you on? .hc On May 14, 2009, at 10:38 AM, brandon zeeb wrote: The toggle shortcut key is still broken, on my machine, it will put a canvas on the page instead of a toggle. ~Brandon On Wed, May 13, 2009 at 8:49 PM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.at wrote: Ok, so this thing is just about ready to release! Please hammer on it, report any little bug or annoyance you might find to the bug tracker! You can see some info about the included changes here: http://puredata.info/dev/NextRelease Windows and Debian/PowerPC builds coming soon http://at.or.at/hans/pd/installers.html .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] startup makes crash + .plist
Marco Donnarumma wrote: Hi list, i have an Urgent problem i realy hope someone could help me quickly. This is the last day for me to prepare a performance for a live show and Pd doesn't open anymore. :( The story i installed pdmtl library (from zip file on MAC) following the video tutorial. I modified Pd preferences (path and startup), close Pd and when i tried to relaunch it, it open a blank consolle and then crash immediately without loading any library (or at least i don-t see in the consolle anything loading). so it doesn-t allow me to modify anymore the preferences. i disinstalled Pd and reinstalled twice but it keeps on with the same behaviour described above (as far as i know the keys are still stored in the system). This suggests that the problem lies in the plist file in ~/Library/Preferences/, as when you re-install Pd, you should be re-installing the default preferences as well (i.e., the plist that lives within the application package contents). Are you re-installing a completely fresh copy? how can i modify the org.puredata.pd.plist file from terminal? i used the command defaults read org.puredata.pd and i see the error in in the flags startup - but i cannot sort out how to modify it from terminal... (sorry for the ignorance but im not used to manage terminal) i also look for org.puredata.pd.plist in |~/Library/Preferences/ |but the file doens't look to be there. That's very odd. There should be org.puredata.pd.plist (as well as org.puredata.pd.wish.pdlist, but ignore that) in ~/Library/Preferences/. It would seem to be the only explanation for the persistence of the problem. By the way, if and when you find org.puredata.pd.plist, just double-click it, and a property editing program will run. Alternatively, just delete it org.puredata.pd.plist from ~/Library/Preferences/ -- that will get you back to default behavior. See here for more info: http://puredata.info/docs/faq/pdsettings or how i disinstall Pd in order to reset all preferences? or any other suggestion is really appreciated, i still have a hell of work to do on the performance patch. : I hope this helps...I'll be around for the next ten hours or so, so write back if you're still stuck. Good luck. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended font paths
Oh, Gem, of course. So when I'm not using Gem, I can safely do without those eight path elements, then? Also, while I'm being a whinging pest...it's impossible to add a path element that lives inside the pd-extended.app folder using the path dialog. This is because OS X makes the .app package not look like a folder, I suppose, but it's unfortunate nevertheless. Off to edit the .plist, I go. Thanks, Hans. Phil Hans-Christoph Steiner wrote: Well, it makes it easier to find fonts. That's the reason. I suppose most people aren't using fonts much with Pd. If [declare -path] works for Gem fonts, then I would consider removing some from the default prefs. .hc On Mar 26, 2009, at 9:23 PM, Phil Stone wrote: Do there really need to be eight different font-related entries in the path list for Pd-extended on OS X? If so, why? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd-extended font paths
Do there really need to be eight different font-related entries in the path list for Pd-extended on OS X? If so, why? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C::NTR::L - AV+physical computing processing
This is very impressive, Marco. What grabs me immediately is that you are demo'ing with bass (nice Steiny or Hohner, btw) - lower-frequency instruments are particularly difficult for pitch-detection. What is the latency? It's hard to tell from the video, but it looks pretty responsive. How accurate? I've been waiting a long time to plug my bass into my Pd stuff. I will be happy to test anything, and also to help with the code cleanup, if it lies within my area of competence. Nice work! Phil Stone www.pkstonemusic.com Marco Donnarumma wrote: Hi all, i'm really glad to share with the list my latest project, cause without the help of everybody here i wouldn't be able to speak about it now.. ;) C::NTR::L is a software, naturally Pd-based, for audiovisual live performances exploiting physical computing. It transforms a standard musical instrument in an augmented tool to control real-time audio-video processing, without the need of any external device (damned expensive) or MIDI. You play your score and to each note is connected an audio, video or audiovisual fx, and you can connect whatever you want with whatever you desire. It's Pd! C::NTR::L is Cross-Platform for Mac, Linux and Windows (so far i've been able to keep the same patch working on all platform, too lucky...) By now it has been succesfully tested with electric bass guitar, guitar, piano (only two octaves working right now), accordion and trumpet. I conceived this project almost three years ago (when i was just starting to get aware of the existence of Pd). I was playing the bass guitar trying to control videos with resolume :( and sound with AudioMulch. wow.. i cannot figure out how! anyway, since my competences and passion for Pd grew up, i decided to make the whole project become a software for public use and to do it exclusively focusing on Pd. Today this is the result (I C::ntr::l Nature, my audiovisual performance for electric bass guitar and butterfly): http://vimeo.com/2225345 I sent out a call for beta-testers on the most used audiovisual-related forums (Pd forum too), i fixed most of the bugs and someone is planning to do things with my lil creature. Now I'm planning the public release of version 1.2 Beta in the end of this month (if i won't be eated by my everyday job). I'm writing to the list not only to let you know the news, but specially because i would like to know if there is anybody out there who has time and will to help me in the cleaning and further development of the code. Being a webdesigner, usability and accessiblity are my first aims. I've many ideas and many suggestions collected in my to-do list, but being alone, the development would be really slow, maybe even pointless. I would be glad to answer to all questions, technical, conceptual and more... and to explain more in depth how C::NTR::L is working. I know everybody is quite busy, infact i would be really glad also of some little help with some taks. I'm also developing a new interface trying to make C::NTR::L user-friendly for real. But this is another issue that i also would like to discuss about with the list. My idea, maybe pretty ingenuos, is to create a software for audiovisual performances so easy to use also for no-Pd'rs, that one would download Pd (and starting to familiarize with it) because of the interest towards C::NTR::L, or any other user-friendly software - unfortunately i don't see many around. For sure it wouldn't happen with millions of people, but maybe it could help in the spreading of Pd, and OS multimedia creation. further link (still have to update some contents, butthe most is there) www.thesaddj.com/cntrl http://www.thesaddj.com/cntrl www.thesaddj.com/icontrolnature http://www.thesaddj.com/icontrolnature sorry for the very very long e-mail. best -- Marco Donnarumma aka The !S.A.D! Multimedia Artist, Live Performer Roma, IT LAB: http://www.thesaddj.com | http://www.flxer.net EVENT: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Good point; I assume you're going to emphasize the pitfalls of dynamic patching while you're at it, Derek? I have a habit of opening up patches to see how they work, and if I can't read them because they're too messy, I'll move stuff around. This is fine, unless it's a dynamic patch and I hit ctrl-s without thinking. D'oh! The initial state of a dynamic patch is critical to its correct function, and one has to think very carefully before saving changes. I think I'm going to develop the habit of putting a large warning comment on any self-modifying patch. Phil IOhannes m zmoelnig wrote: however, my experiences with abcde were the main reason i s did not touch self-modifying patches for years and years. the lesson i learned was: never do self-modification in patches that other people will ever have to regularily use. (the original phrase would have been never do self-modification in patches that other people will ever have to maintain; however, this might give the impression that chances are low that somebody else will really have to maintain a patch); in practice you pass maintainership to somebody as soon as you give them your patch: they will eventually start to modify it. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
I may not be thinking this through correctly, but how do you handle broken connections with inlets/outlets in the cleared subpatch? I.e., the containing patch will lose its patch connections to the inlets/outlets of the subpatch if the sbupatch is cleared. Phil With certain clean patching habits it's not that bad. For example the original nqpoly4 was rather messy because it did the dynamic patching in the abstraction itself, used namcanvas for it and thus relied on a certain initial state. What I changed was to remove namcanvas, do the dynamic patching inside of a subpatch and started with clearing that patch from a loadbang. A loadbanged [; pd-subpatch clear( IMO is mandatory for dynamic patching in abstractions. Even if it's saved with old content that will be removed on the next load. Another use for dynamic patching is automatically creating parts of static patches. For example my piece Frost on the GOSUB10 netlabel release uses 60 resonant bandpass filters driven by noise bursts. Of course I didn't patch all of these manually and changed their arguments, instead I used dynamic patching to generate the filter bank once, which then was saved into a static patch. In that use case, one should not use a loadbang'd clear of course. ;) To add another example: I use dynamic patching in the list-abs-intro.pd patch to generate a list of all list-abs in the [list]-abs collection. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Hi Derek, Maybe a very simple example would be good. I have an Ozone MIDI-controller, and it has eight knobs, which send out continuous controller data on 8 different MIDI CC numbers. Now, [ctlin] (MIDI control input) doesn't have settable arguments -- only creation args., so I racked my brains trying to figure out how to make an object that would take a knob number argument, 1-8, convert that number to the corresponding controller number, and watch that controller number with [ctlin]. (Admittedly, it would have been easy to create [Ozknob1]...[Ozknob8] objects, but this reeked of kludge to my sensibilities; neither did I consider it elegant to use a [ctlin] for each knob that watched *all* controller data, then [route]d the data from the desired control number -- I wanted the pre-filtering to be done by [ctlin], if possible). The more generalized problem is this: take a creation argument of an abstraction, *do something with it*, then get it into the creation argument of a contained abstraction. Nothing I tried worked, until I took the attached dynamic approach. Phil Stone www.pkstonemusic.com Derek Holzer wrote: Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek #N canvas 676 96 394 341 10; #X obj 8 105 21; #X obj 34 105 22; #X obj 60 105 23; #X obj 86 105 24; #X obj 112 105 25; #X obj 138 105 26; #X obj 164 105 27; #X obj 189 105 28; #X obj 37 74 select 1 2 3 4 5 6 7 8; #X obj 37 51 f \$1; #X obj 37 6 loadbang; #X obj 103 304 outlet; #X text 8 149 Ozone mapping; #X msg 237 93 2; #X text 267 91 channel; #X obj 37 28 t b b; #X obj 102 158 pack f f; #X text 110 16 Use: [OzKnob n] where n is the knob #; #N canvas 0 22 210 111 \$0-oz_ctrlknob 0; #X obj 28 72 outlet; #X restore 103 272 pd \$0-oz_ctrlknob; #X obj 102 218 s pd-\$0-oz_ctrlknob; #X msg 102 187 obj 10 10 ctlin \$1 \$2 \, connect 1 0 0 0; #X connect 0 0 16 0; #X connect 1 0 16 0; #X connect 2 0 16 0; #X connect 3 0 16 0; #X connect 4 0 16 0; #X connect 5 0 16 0; #X connect 6 0 16 0; #X connect 7 0 16 0; #X connect 8 0 0 0; #X connect 8 1 1 0; #X connect 8 2 2 0; #X connect 8 3 3 0; #X connect 8 4 4 0; #X connect 8 5 5 0; #X connect 8 6 6 0; #X connect 8 7 7 0; #X connect 9 0 8 0; #X connect 10 0 15 0; #X connect 13 0 16 1; #X connect 15 0 9 0; #X connect 15 1 13 0; #X connect 16 0 20 0; #X connect 18 0 11 0; #X connect 20 0 19 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] music made with Pd
Hi, I'm trying out this website called soundcloud.com, which seems to be a fairly decent way of sharing music without much nonsense. Anyway, I uploaded a recent piece I made (completely with Pd, naturally!): http://soundcloud.com/putahslim/intrinsic Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbol anxiety
Mathieu Bouchard wrote: On Mon, 23 Feb 2009, Roman Haefeli wrote: for instance, when using OSC, probably every message is a new symbol. so i guess, it cannot be avoided, even if text processing is done outside of pd, unless a string type is introduced (is that correct?). Every OSC target is a symbol, just like every receive-symbol is a symbol; but furthermore, even hierarchical names like /foo/bar are recorded as a single name that doesn't use foo and bar, instead of using a list. Similarly, abstraction instances are _the_ way to flood the table, as all the local receive-symbols and other local symbols get multiplied by the number of instances. I proposed several solutions to this. Having deallocatable symbols only is useful if you deallocate abstractions and reallocate them... usually has to do with dynamic patching. The other solution would be to make the symbol-table only a table of symbols, and have a separate receiver-table, which would get accessed by ($0,symbol) pairs so that the $0 doesn't get pasted inside of the symbol so that no more symbols need be generated. That would be quite a major overhaul, but it's pretty much the only real solution. I don't think that there's anything else in OSC that could be wasting symbols. However, if you have a system where you use 100 OSC-paths to represent an array of 100 numbers, you may be looking for trouble. Since OSC messages have some value concatenated to the end, aren't they all potentially unique and therefore consumers of new symbols? E.g., /oscillator/frequency 440.0 and /oscillator/frequency 449.365 require distinct symbols, don't they? And to think I was worried about a little stopwatch! :-) Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbol anxiety
Phil Stone wrote: Mathieu Bouchard wrote: On Mon, 23 Feb 2009, Roman Haefeli wrote: for instance, when using OSC, probably every message is a new symbol. so i guess, it cannot be avoided, even if text processing is done outside of pd, unless a string type is introduced (is that correct?). Every OSC target is a symbol, just like every receive-symbol is a symbol; but furthermore, even hierarchical names like /foo/bar are recorded as a single name that doesn't use foo and bar, instead of using a list. Similarly, abstraction instances are _the_ way to flood the table, as all the local receive-symbols and other local symbols get multiplied by the number of instances. I proposed several solutions to this. Having deallocatable symbols only is useful if you deallocate abstractions and reallocate them... usually has to do with dynamic patching. The other solution would be to make the symbol-table only a table of symbols, and have a separate receiver-table, which would get accessed by ($0,symbol) pairs so that the $0 doesn't get pasted inside of the symbol so that no more symbols need be generated. That would be quite a major overhaul, but it's pretty much the only real solution. I don't think that there's anything else in OSC that could be wasting symbols. However, if you have a system where you use 100 OSC-paths to represent an array of 100 numbers, you may be looking for trouble. Since OSC messages have some value concatenated to the end, aren't they all potentially unique and therefore consumers of new symbols? E.g., /oscillator/frequency 440.0 and /oscillator/frequency 449.365 require distinct symbols, don't they? And to think I was worried about a little stopwatch! :-) On further reflection, the OSC path (which *is* a symbol) and the value (which *may* be a symbol, but is more typically a float) are two list items, so the answer to my question is no, I think. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbol anxiety
Frank Barknecht wrote: Hallo, Phil Stone hat gesagt: // Phil Stone wrote: Attached is [maketime], a lovely little timer/stopwatch. I've long since lost track of who made it, so I'm sorry can't give you well-deserved credit here. At any rate, it creates *at least* one symbol per second (probably more, I'm not sure if each [makefilename] generates a new symbol, but I'm guessing it does). This makes me nervous, as I have no idea what the symbol table capacity is, or how to see how full it is. It seems likely that this abstraction would crash eventually. A fix for this maketime would be to reuse the symbols :00 ... :59 for minutes and hours by using two [cnv] objects for these. Then you would be able to let the clock run for decades before you get into trouble with the symbol table. I've pondered this, and can't figure out what you mean, unless you're suggesting having 60 canvases, one for each possible number? I did re-work [maketime] a little. Attached is a version (called [ps-stopwatch] that adds some features and only creates one symbol per second (plus one per minute, plus one per hour); the original created six per second. The new one requires zexy's [makesymbol] (which can convert lists of numbers into a single symbol -- perfect for this application, but not in Vanilla-Pd, obviously). Every table or receiver or route-selector etc. also is a symbol. Yes, but except in some extreme examples of dynamic programming, this is a known quantity. My anxiety comes from the memory leak behavior of long-running patches that dynamically create symbols (anything that does any sort of string handling is in this category, usually). It would be so much better to have transient symbols for this sort of thing, but as Mathieu said, it sounds like this is not going to happen any time soon. So while the implementation of the symbol table is suboptimal, in practice it's not something you need to worry about too much. At least it should not make you replace [route freq note] with [route 0 1] :-) Just to see the magnitude of the issue, I made a little test patch (attached) called [symbol_pig]. It just creates symbols, very fast. A very rough measurement based on watching resident memory increasing in bash's top command indicates that (on OS X 10.4), a megabyte is used up for approximately every 32,000 symbols. Phil #N canvas 0 22 450 300 10; #X obj 109 47 metro 10; #X obj 146 80 + 1; #X obj 109 79 f 0; #X obj 109 117 makefilename %d; #X symbolatom 109 148 10 0 0 0 - - -; #X obj 109 23 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X connect 0 0 2 0; #X connect 1 0 2 1; #X connect 2 0 1 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 5 0 0 0; #N canvas 788 73 273 360 12; #X declare -lib zexy; #X obj 1 1 cnv 15 156 30 empty \$0-time_display 0:03:36 6 15 0 24 -1 -241291 0; #X obj 71 224 + 1; #X obj 37 223 f; #X msg 163 56 0; #X obj 163 1 loadbang; #N canvas 337 282 345 318 sec-to-time-symbol 0; #X obj 13 7 inlet; #X obj 14 291 outlet; #X obj 13 63 % 60; #X obj 231 95 int; #X obj 182 6 import zexy; #X obj 95 124 change -1; #X obj 95 72 / 60; #X obj 231 69 / 3600; #X obj 95 98 int; #X obj 13 34 t f f f; #X obj 231 121 change -1; #X obj 231 177 makesymbol %s; #X obj 95 208 list prepend; #X obj 14 237 list prepend; #X obj 95 150 % 60; #X obj 14 264 makesymbol %s:%02s:%02s; #X obj 95 177 makesymbol %02s; #X obj 13 89 list; #X obj 231 149 % 100; #X connect 0 0 9 0; #X connect 2 0 17 0; #X connect 3 0 10 0; #X connect 5 0 14 0; #X connect 6 0 8 0; #X connect 7 0 3 0; #X connect 8 0 5 0; #X connect 9 0 2 0; #X connect 9 1 6 0; #X connect 9 2 7 0; #X connect 10 0 18 0; #X connect 11 0 12 1; #X connect 12 0 13 1; #X connect 13 0 15 0; #X connect 14 0 16 0; #X connect 15 0 1 0; #X connect 16 0 12 0; #X connect 17 0 13 0; #X connect 18 0 11 0; #X restore 37 252 pd sec-to-time-symbol; #X obj 3 46 r \$0-start; #X obj 124 1 bng 14 250 50 0 \$0-start empty empty 17 7 0 10 -4034 -1 -1; #X obj 124 17 bng 14 250 50 0 \$0-stop empty empty 17 7 0 10 -258113 -1 -1; #X obj 141 9 bng 14 250 50 0 \$0-reset empty empty 17 7 0 10 -262144 -1 -1; #X obj 176 29 r \$0-reset; #X obj 80 46 r \$0-stop; #X msg 3 71 1; #X msg 80 71 0; #X obj 37 121 f 0; #X msg 199 130 -1; #X obj 113 223 symbol -:--:--; #X obj 37 150 metro 1000; #X obj 37 289 list prepend; #X obj 215 252 f \$0; #X obj 163 81 t b b b f f b; #X msg 37 317 \; \$1-time_display label \$2; #X connect 1 0 2 1; #X connect 2 0 1 0; #X connect 2 0 5 0; #X connect 3 0 20 0; #X connect 4 0 3 0; #X connect 5 0 18 0; #X connect 6 0 12 0; #X connect 10 0 3 0; #X connect 11 0 13 0; #X connect 12 0 14 0; #X connect 13 0 14 0; #X connect 14 0 17 0; #X connect 15 0 1 0; #X connect 16 0 18 0; #X connect 17 0 2 0; #X connect 18 0 21 0; #X connect 19 0 18 1; #X connect 20 0 14 0; #X connect 20 1 16 0; #X connect 20 2 15 0; #X connect 20 3 2 0; #X connect 20 4 17 0; #X connect 20 5 19 0; #X coords 0 -1 1 30 158 32 1 0 0
Re: [PD] symbol anxiety
Frank Barknecht wrote: Hallo, Phil Stone hat gesagt: // Phil Stone wrote: Frank Barknecht wrote: A fix for this maketime would be to reuse the symbols :00 ... :59 for minutes and hours by using two [cnv] objects for these. Then you would be able to let the clock run for decades before you get into trouble with the symbol table. I've pondered this, and can't figure out what you mean, unless you're suggesting having 60 canvases, one for each possible number? No, only two canvases, one for minutes, one for seconds. See attachment. This way you only ever generate 60 different symbols. As existing symbols are reused, your memory usage doesn't grow after that. Oh! Very good. I didn't realize that an identical symbol would get re-used. For completeness' sake, I will make a new [ps-stopwatch] that does not leak (and is plain vanilla, to boot). Cheers, Frank. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] A non-leaky stopwatch
Hello, Attached is a stopwatch, derived from [maketime], that doesn't pollute the symbol table (i.e., indefinitely leak memory), thanks to Frank B.'s idea for keeping the symbols re-usable. It has one-second grain, so it does not keep track of partial seconds between stops and restarts-with-no-reset. However, it is quite accurate after resets and when first started. I learned that metro sends an immediate bang when started -- something I had never paid attention to before. So [ps-stopwatch] always skips the first bang out of [metro] (after reset) so that it isn't one second ahead. It counts up to 99 hours, 59 minutes, and 59 seconds, then wraps back to zero. It would be easy to make this a finer-grain stopwatch, down to the inherent resolution of [metro]. However, for my purposes (timing of live performance) one-second grain is quite adequate, and not too CPU-hungry. Thanks again to Frank for this elegant solution. Phil Stone www.pkstonemusic.com #N canvas 788 73 452 547 10; #X obj 1 1 cnv 15 32 30 empty \$0-hours empty 5 15 0 24 -1 -241291 0; #X obj 34 1 cnv 15 46 30 empty \$0-minutes :01 3 15 0 24 -1 -241291 0; #X obj 80 1 cnv 15 77 30 empty \$0-seconds :58 0 15 0 24 -1 -241291 0; #X obj 163 1 loadbang; #X obj 144 10 bng 12 250 50 0 \$0-reset empty empty 17 7 0 10 -262144 -1 -1; #X obj 17 126 f 0; #X msg 208 488 label \$1; #X obj 208 515 s \$0-hours; #X msg 279 488 label \$1; #X obj 279 515 s \$0-minutes; #X msg 360 488 label \$1; #X obj 360 515 s \$0-seconds; #X obj 307 149 symbol :--; #X obj 297 173 symbol --; #X obj 16 255 f 0; #X obj 46 255 + 1; #X obj 16 281 mod 60; #X obj 16 333 f 0; #X obj 46 333 + 1; #X obj 16 354 mod 60; #X obj 16 307 select 0; #X obj 80 306 makefilename :%02d; #X obj 82 383 makefilename :%02d; #X obj 16 413 f 0; #X obj 46 413 + 1; #X obj 16 383 select 0; #X obj 16 434 mod 99; #X obj 82 458 makefilename %2d; #X text 265 10 goes up to 99 hours \, then; #X text 266 24 wraps back to zero.; #X msg 53 126 0; #X obj 176 23 r \$0-reset; #X msg 130 199 0; #X obj 16 228 spigot 0; #X msg 84 181 0; #X obj 17 181 t b a; #X msg 17 204 1; #X obj 215 252 symbol 0; #X obj 225 273 symbol :00; #X obj 215 200 spigot 0; #X obj 163 48 t b b b b b b; #X msg 250 172 0; #X msg 220 172 1; #X obj 215 224 t b b; #X obj 173 173 sel 1; #X text 265 57 doesn't remember partial; #X text 265 71 seconds between restarts; #X obj 17 154 metro 1000; #X obj 125 8 tgl 17 0 \$0-onoff \$0-r-onoff empty 17 7 0 10 -24198 -1 -262144 1 1; #X obj 355 292 s \$0-r-onoff; #X msg 355 267 color \$1 0; #X msg 354 243 13; #X msg 384 243 16; #X obj 16 34 r \$0-onoff; #X obj 83 125 sel 0; #X obj 16 57 t f f f; #X obj 16 82 s \$0-color; #X obj 354 196 r \$0-color; #X obj 354 219 sel 0 1; #X text 41 202 skip 1st bang; #X connect 3 0 40 0; #X connect 5 0 44 0; #X connect 5 0 47 0; #X connect 6 0 7 0; #X connect 8 0 9 0; #X connect 10 0 11 0; #X connect 12 0 10 0; #X connect 12 0 8 0; #X connect 13 0 6 0; #X connect 14 0 16 0; #X connect 15 0 14 1; #X connect 16 0 15 0; #X connect 16 0 20 0; #X connect 16 0 21 0; #X connect 17 0 19 0; #X connect 18 0 17 1; #X connect 19 0 18 0; #X connect 19 0 22 0; #X connect 19 0 25 0; #X connect 20 0 17 0; #X connect 21 0 10 0; #X connect 22 0 8 0; #X connect 23 0 26 0; #X connect 24 0 23 1; #X connect 25 0 23 0; #X connect 26 0 24 0; #X connect 26 0 27 0; #X connect 27 0 6 0; #X connect 30 0 47 0; #X connect 31 0 40 0; #X connect 32 0 15 0; #X connect 32 0 18 0; #X connect 32 0 24 0; #X connect 33 0 14 0; #X connect 34 0 33 1; #X connect 35 0 36 0; #X connect 35 1 33 0; #X connect 36 0 33 1; #X connect 37 0 6 0; #X connect 37 0 8 0; #X connect 38 0 10 0; #X connect 39 0 43 0; #X connect 40 0 5 0; #X connect 40 1 32 0; #X connect 40 2 13 0; #X connect 40 2 12 0; #X connect 40 3 34 0; #X connect 40 4 42 0; #X connect 40 5 30 0; #X connect 41 0 39 1; #X connect 42 0 39 1; #X connect 43 0 41 0; #X connect 43 1 37 0; #X connect 43 1 38 0; #X connect 44 0 39 0; #X connect 47 0 35 0; #X connect 50 0 49 0; #X connect 51 0 50 0; #X connect 52 0 50 0; #X connect 53 0 55 0; #X connect 54 0 34 0; #X connect 55 0 56 0; #X connect 55 1 54 0; #X connect 55 2 5 0; #X connect 57 0 58 0; #X connect 58 0 51 0; #X connect 58 1 52 0; #X coords 0 -1 1 30 158 32 1 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] symbol anxiety
Hi everybody, Ever since I first started programming with Pd, I have had a vague anxiety about symbols, or to be more exact, symbol table growth. Now, I've never run into a problem in real life, but the worry is still there, nagging at me, ever since I read on a Pd-list thread that each symbol takes up permanent, un-reclaimable space in a symbol table. So, I've always been wary about employing many symbols, or having some dynamic process that creates many symbols on the fly. Attached is [maketime], a lovely little timer/stopwatch. I've long since lost track of who made it, so I'm sorry can't give you well-deserved credit here. At any rate, it creates *at least* one symbol per second (probably more, I'm not sure if each [makefilename] generates a new symbol, but I'm guessing it does). This makes me nervous, as I have no idea what the symbol table capacity is, or how to see how full it is. It seems likely that this abstraction would crash eventually. A) Is it true that [maketime] would continually grow the symbol table? B) Is it possible to tell how full the symbol table is? How much memory is allocated to it in the first place? C) Wouldn't it be nice to have some truly transient symbols, that could be abstraction-local, or at least, re-usable? Cheers, Phil Stone #N canvas 300 22 311 311 12; #X obj 36 10 cnv 15 220 40 empty *time-display-cnv-in* 0:00:00 20 18 0 36 -1 -241291 0; #X msg 35 235 \; *time-display-cnv-in* label \$1; #X obj 69 155 + 1; #X obj 35 154 f; #X obj 35 111 metro 1000; #X msg 133 111 0; #X obj 35 83 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X floatatom 35 182 5 0 0 0 - - -; #X obj 133 85 loadbang; #N canvas 0 22 450 459 sec-to-time-symbol 0; #X obj 24 17 inlet; #X obj 50 337 outlet; #X msg 84 258 set \$1; #X obj 50 312 makefilename not-set-yet; #X floatatom 50 258 0 0 0 0 - - -; #X msg 171 177 set \$1; #X obj 84 205 makefilename not-set-yet; #N canvas 0 22 450 300 format 0; #X obj 24 20 inlet; #X obj 24 224 outlet; #X obj 91 105 + 1; #X obj 24 47 t f f; #X obj 24 171 makefilename 0%d; #X obj 176 171 makefilename %d; #X obj 91 80 = 10; #N canvas 0 22 450 300 gate2 0; #X obj 44 237 spigot; #X obj 44 262 outlet; #X obj 123 238 spigot; #X obj 123 263 outlet; #X obj 21 30 inlet; #X obj 288 38 inlet; #X obj 359 129 loadbang; #X obj 93 194 unpack 0 0; #X obj 288 62 route 0 1 2; #X msg 350 95 0 1; #X msg 319 127 1 0; #X msg 288 166 0 0; #X connect 0 0 1 0; #X connect 2 0 3 0; #X connect 4 0 0 0; #X connect 4 0 2 0; #X connect 5 0 8 0; #X connect 6 0 11 0; #X connect 7 0 0 1; #X connect 7 1 2 1; #X connect 8 0 11 0; #X connect 8 1 10 0; #X connect 8 2 9 0; #X connect 9 0 7 0; #X connect 10 0 7 0; #X connect 11 0 7 0; #X restore 24 133 pd gate2; #X connect 0 0 3 0; #X connect 2 0 7 1; #X connect 3 0 7 0; #X connect 3 1 6 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 2 0; #X connect 7 0 4 0; #X connect 7 1 5 0; #X restore 84 177 pd format; #X obj 171 84 % 60; #X obj 85 82 / 60; #X obj 85 115 int; #X obj 84 142 % 60; #X obj 24 115 int; #X obj 24 82 / 3600; #X obj 24 44 t f f f; #X obj 84 234 makefilename %%d:%s; #X obj 171 153 makefilename %%s:%s; #N canvas 0 22 450 300 format 0; #X obj 24 20 inlet; #X obj 24 224 outlet; #X obj 91 105 + 1; #X obj 24 47 t f f; #X obj 24 171 makefilename 0%d; #X obj 176 171 makefilename %d; #X obj 91 80 = 10; #N canvas 0 22 450 300 gate2 0; #X obj 44 237 spigot; #X obj 44 262 outlet; #X obj 123 238 spigot; #X obj 123 263 outlet; #X obj 21 30 inlet; #X obj 288 38 inlet; #X obj 359 129 loadbang; #X obj 93 194 unpack 0 0; #X obj 288 62 route 0 1 2; #X msg 350 95 0 1; #X msg 319 127 1 0; #X msg 288 166 0 0; #X connect 0 0 1 0; #X connect 2 0 3 0; #X connect 4 0 0 0; #X connect 4 0 2 0; #X connect 5 0 8 0; #X connect 6 0 11 0; #X connect 7 0 0 1; #X connect 7 1 2 1; #X connect 8 0 11 0; #X connect 8 1 10 0; #X connect 8 2 9 0; #X connect 9 0 7 0; #X connect 10 0 7 0; #X connect 11 0 7 0; #X restore 24 133 pd gate2; #X connect 0 0 3 0; #X connect 2 0 7 1; #X connect 3 0 7 0; #X connect 3 1 6 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 2 0; #X connect 7 0 4 0; #X connect 7 1 5 0; #X restore 171 116 pd format; #X connect 0 0 14 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 4 0 3 0; #X connect 5 0 6 0; #X connect 6 0 15 0; #X connect 7 0 6 0; #X connect 8 0 17 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 11 0 7 0; #X connect 12 0 4 0; #X connect 13 0 12 0; #X connect 14 0 13 0; #X connect 14 1 9 0; #X connect 14 2 8 0; #X connect 15 0 2 0; #X connect 16 0 5 0; #X connect 17 0 16 0; #X restore 35 208 pd sec-to-time-symbol; #X text 176 111 reset time; #X text 57 83 start; #X connect 2 0 3 1; #X connect 3 0 2 0; #X connect 3 0 7 0; #X connect 4 0 3 0; #X connect 5 0 7 0; #X connect 5 0 3 1; #X connect 6 0 4 0; #X connect 7 0 9 0; #X connect 8 0 5 0; #X connect 9 0 1 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management
Re: [PD] here I go again..dynamic abstractions
Frank Barknecht wrote: I see a third option: $0 is not only different from the $-variables in message boxes, but it's also different from the $-variables used as object arguments.[1] So another way out would be to replace only $0 with something like #0. Yes. This, at least, would end the irrelevant dollar sign variables in message boxes are different than abstraction initializers argument every time someone asks why $0 can't be used in a message box. :-) Also, it would be much less confusing in general, because $0 never means the same thing as $1...$n, inside *or* outside of message boxes. Of course beginners then still would like to use #0 in a message box. I'm not a beginner (though far from an expert), and I still want to use the unique identifier in message boxes. What, exactly, is wrong with that use case? Frank, I think you make quite a bit of use of $0 in messages in [memento], for example. If it's wrong, why does the idiom; [f $0]-[message $1( get suggested as a solution so often? In my opinion, that's just a kludge, avoiding the original problem. Looking back on the thread, I see this from Iohannes: $-args in message-boxes are a way to modify messages. since messages don't have a patch-context, neither have (their patchable instances) message-boxes. But the message-boxes *do* have a patch context; they live in an abstraction that has a unique identifier, which is sometimes useful to blend into a message. I'm sorry for being stubborn about this, but I still don't see Georg's basic question answered, just a lot of dancing around it. :-) Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] here I go again..dynamic abstractions
Frank Barknecht wrote: Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Sat, 7 Feb 2009, Frank Barknecht wrote: Messages don't have anything comparable to the canvas' $0. I missed this the first time it went by, and I think it's central to (my) confusion about this... Messages don't have anything comparable to the canvas' $0, but *message boxes do*! Why, therefore, is $0 not valid in a message box (as a way of embedding the canvas-identifier into a message), and further, why are people going so far as to suggest new, orthogonal meanings for $0 in a message box? Please, don't do this; it would only make the situation much more confusing! Arrgh! Phil A possible alternative use for $0 in messages would be the selector (list, symbol, ...) as that is the thing before $1, but implementing that could be even more confusing to beginners. Why would that be confusing to beginners? Because it's not the $0 from object boxes. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] here I go again..dynamic abstractions
This has been an interesting discussion about the philosophy behind dollar-sign symbols in Pd, but it seems to me like most participants are talking around Georg's original point at the head of the thread: it's inconvenient to get $0 (the unique-id-for-this-abstraction value) into a message, and its exclusion from message boxes seems arbitrary. Why arbitrary? It's very clear that dollar symbols mean different things in messages than they do in abstractions -- that is not the issue. In fact, $0 is a special case *when used as an abstraction parameter* as well -- it does not have anything close to the same meaning or function as $1, $2, etc. (i.e., initialization parameters). Yet, it is still allowed in abstractions. Why does the same reasoning not hold for message boxes? It is a perfectly valid use-case to send an abstraction-id (from the message's containing abstraction) in a message. This whole question might have been avoided if $0 did not start with a dollar sign (I think someone mentioned this already). But just because it does, why is it excluded from message boxes? At least one other response in this thread has gone so far as to suggest that since $0 doesn't have any meaning in a message box, it should be overloaded for something else (other than the unique abstraction identifier). No, please! :-) Despite all the discussion in this thread, I have yet to see a reason for this exclusion that wouldn't apply equally to using $0 as an abstraction-id. Phil Stone pkstonemusic.com Mike McGonagle wrote: On Mon, Feb 9, 2009 at 3:45 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I think it would make sense (both pedagogically and practically) if $0 in message boxes actually _did_ something. Incrementing per message box would be one option, but expanding to a user-defined symbol or float could be very useful: Actually, for me, I always think of the word CONTEXT. An abstraction is one context, and the meanings of the $ args means one thing. While in a message, a $ arg means something completely different. Once I realized that the two are not the same thing, it made sense. If the $ args had the same meanings in both an abstraction and a message, there would be no way to create a message inside of an abstraction that allowed for $ args that were unrelated to the $ args in the abstraction. In other words, if they were the same thing, there would be no way to create a variable message that had more args than there were in the abstraction itself. Mike [loadbang] | [f $0] | [; set $0( That way, message box $0 is set by an incoming message: it then sets all current (and future) message box $0's for the patch/abstraction. Alternatively, you could use it for other stuff, like a substitution for pd-my-complicated-and-tiresome-to-type-subpatch-name. abstraction $0: set by pd, unique abs instance identifier, common to all object boxes message box $0: set by user through msg box, common to all abstraction instance msg's Seems like that would be consistent with the language as far as I understand it. -Jonathan --- On Mon, 2/9/09, Matt Barber brbrof...@gmail.com wrote: From: Matt Barber brbrof...@gmail.com Subject: Re: [PD] here I go again..dynamic abstractions To: PD-List pd-list@iem.at Date: Monday, February 9, 2009, 9:01 PM [f $0]-[message $1( is conceptually different from [message $0( for the same reason that [f $2]-[message $1( is conceptually different from [message $2( (and would be, even if $0 had any meaning in a message box). When I teach I always start with dollar-sign expansion in message-boxes, since it's simpler and easier to comprehend. Then when this issue comes up when they move to dollar-sign expansion in abstractions (and it always does come up), you can help them think it through with what they already know about message boxes. I only see two options: one is to use a different dereference symbol for abstraction arguments in message boxes -- but why worry with that since it's easy enough to get abstraction arguments into messages at run-time? -- the other is to make an exception and have special behavior for $0 in message boxes (that is, make it the same as in object boxes) -- but then this probably breaks the consistency of the language. Matt Date: Mon, 09 Feb 2009 13:33:36 +0100 From: Georg Werner ge...@fricklr.de Subject: Re: [PD] here I go again..dynamic abstractions To: pd-list@iem.at Message-ID: 499022a0.7080...@fricklr.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed hi, Frank Barknecht: How about making $0 in messages be a message counter? if somebody really needs that - i dont ;) ok, i give up. i think we are on a rather philosophical point now. but i had a lot of times when students where asking why they have
Re: [PD] Nice distortion
Frank Barknecht wrote: Hallo, oops, I sent a version with a missing connectin to the rpole~ coefficient. Please use this one instead. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list I've been having a blast with this effect -- really great, Frank! It doesn't seem too CPU-hungry, either, though that's just an impression not yet quantified. One little thing...the meaning of wet/dry seems to be reversed; i.e. 0 gives full effect, 1 gives no effect. Thanks for making this available. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Possible to unselect radio buttons?
Is there any way to make there be *no* selection displayed in a radio button control? If not, this would be a very useful feature in that it would allow multiple banks of radio buttons to be tied together programatically. I.e., imagine a set of four hradio controls, stacked on top of each other. Any selection in any of the four becomes the current selection, but also turns off all other banks' selection indicators. Whereas a single 64-position radio control would be awkward to deal with graphically, 8 rows of 8-pos. hradio controls would be nice and compact. Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Possible to unselect radio buttons?
That's a pretty brilliant hack, Luke. Thanks for the idea. Phil Luke Iannini wrote: Hi Phil! I've hacked this in before by using a bunch of [moses] objects and sending [color 1 1 1( etc. messages to the radio objects that are supposedly not selected (which makes the radio indicator the same color as the background so it looks like there's nothing there). I'd be happy to dig up a patch if you want to see a demo (but of course some way to do this built in to the IEMgui would be much faster : ) ) Cheers Luke On Thu, Dec 18, 2008 at 1:06 PM, Phil Stone pkst...@ucdavis.edu wrote: Is there any way to make there be *no* selection displayed in a radio button control? If not, this would be a very useful feature in that it would allow multiple banks of radio buttons to be tied together programatically. I.e., imagine a set of four hradio controls, stacked on top of each other. Any selection in any of the four becomes the current selection, but also turns off all other banks' selection indicators. Whereas a single 64-position radio control would be awkward to deal with graphically, 8 rows of 8-pos. hradio controls would be nice and compact. Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Possible to unselect radio buttons?
Steffen, Auto-generated matrix and everything! By the way, [fire64] wouldn't instantiate, but it apparently had done its work before you saved the abstraction, so the matrix worked fine. Very, very cool. Phil Steffen Leve Poulsen wrote: Hi Phil here's one attached bang-matrix.pd mvh/steffen leve poulsen Phil Stone skrev: That's a pretty brilliant hack, Luke. Thanks for the idea. Phil Luke Iannini wrote: Hi Phil! I've hacked this in before by using a bunch of [moses] objects and sending [color 1 1 1( etc. messages to the radio objects that are supposedly not selected (which makes the radio indicator the same color as the background so it looks like there's nothing there). I'd be happy to dig up a patch if you want to see a demo (but of course some way to do this built in to the IEMgui would be much faster : ) ) Cheers Luke On Thu, Dec 18, 2008 at 1:06 PM, Phil Stone pkst...@ucdavis.edu wrote: Is there any way to make there be *no* selection displayed in a radio button control? If not, this would be a very useful feature in that it would allow multiple banks of radio buttons to be tied together programatically. I.e., imagine a set of four hradio controls, stacked on top of each other. Any selection in any of the four becomes the current selection, but also turns off all other banks' selection indicators. Whereas a single 64-position radio control would be awkward to deal with graphically, 8 rows of 8-pos. hradio controls would be nice and compact. Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] puredata.info down?
puredata.info times out -- anybody know if it's up? Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
hard off wrote: hi againsome more comments 1) at first i also tried changing the ADSR sliders to a log setting, and totally understand what you mean about the low values and clicking. my workaround was just to change the range from 1-5000 to 5-5000. however, i think an even better solution is not the log function, but an exponential one. if you change the sliders to 0-1 range and then do: [r slider-value] | [pow 2] (or 3) | [* 5000] | [+ 1] then that gives the most user-friendly sliders in my opinion. Be aware that that breaks the way state is currently saved for the ADSR; ADR values are stored as milliseconds, not as 0-1. That could be changed, but it would break all existing patches (I'm probably the only one for whom that causes problems -- still I try not to do it too often). The log setting is a pretty good compromise; thanks again for the idea. 2) i understand that you can change the pan position and speed, but unless i'm mistaken, there is no way just to keep everything centre panned. Just change the radio button from rnd (for random panning) to fix (for fixed position). Then, move the position slider to the center (or move it live for manual panning). Sorry that the controls are labeled so cryptically, but real estate is at a premium, and the web page documentation spells out the details. i think a pan width slider would be helpful. however, maybe that's just something i want and wouldn't be that important for anyone else, so i might just put that on my own modified version. Yeah, I thought of some other panning algorithms and enhancements besides random panning, too, but have punted this off to OSC control. You can do just about anything you can conceive of through the OSC input, as you are completely in control of what numbers you pass in. Most of my latest work with these two synths involves hooking up LFOs and other data generators to various controls through the OSC input. That said, I *do* plan to balance the panning a little better at some point. It's a simple-minded pan right now, not a balanced-power ratio, so there's a center hole effect. 3) not sure what was happening with the gain problem. perhaps svf~ puts out some gnarly peaks that are well above the -1 1 threshold, and that was making things sound weird when i changed volume. the problem seems fine now, because i deleted the gain section from the polywavevoice~ abtraction and put the gain directly onto the ouptut of polywavesynth~. Well, I'm glad you're not shy about customizing, but that change wipes out the possibility of phased-in preset changes (as when the global toggle is off). I've gone back and forth on this during the evolution of the instrument, and am really liking the current set up which allows local-per-voice gain changes, over-rideable with the global control, which causes all voices to be controlled instantly by the GUI and OSC. the gain slider also had a really unusable range, so i also adjusted that into a more manageable range. It is greater than unity gain above about 70% or so. This was done to match up with [polygrainsynth], which sometimes needs the extra gain. When you have a rack of these, with the two types mixed together, it's good to have the gain slider-range match, but otherwise, you're right that the gain slider could be better optimized for [polywavesynth]'s purposes. i will definitely use this synth a lot from now on. today i was running it with an SH101 emulator i am making, and a modified sequenced version of frank's vosim~ abstraction, and some drum synths, and it was all sounding pretty sweet. really cool to be able to get some polyphony happening and do chords and stuff! That's really great to hear, and I look forward to hearing some music made with it. Check out [polygrainsynth] if you get a chance. Thanks a million for the detailed feedback, Phil http://www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
Sorry for the self-reply, hard off pointed out a hole in the documentation to [polywavesynth] and [polygrainsynth]: Phil Stone wrote: hard off wrote: 2) i understand that you can change the pan position and speed, but unless i'm mistaken, there is no way just to keep everything centre panned. Just change the radio button from rnd (for random panning) to fix (for fixed position). Then, move the position slider to the center (or move it live for manual panning). Sorry that the controls are labeled so cryptically, but real estate is at a premium, and the web page documentation spells out the details. I double-checked, and it looks like I left out any explanation of how panning works from the web page docs. Oops. I'll remedy that very soon. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
Thanks for the feedback, Mr. Off. :-) Seriously, I really appreciate it. (responses interleaved below). hard off wrote: yeah getting some quite lush sounds out of this polywavesynth now. says its only using 4% of my cpu as well, which is a bonus. haven't tried the grain one yet. Fast machine! This means you can use big voice numbers, like 64 (if you can find a use for that kind of polyphony). Alternatively, you can throw up multiple [polywavesynth]s and/or [polygrainsynth]s, for polytimbral polyphony, or fattened unison voices. a couple of things: 1) the message box going into the sssadpanel currently contains [example_presets/example1( but the folder is actually [Example_Presets], my system doesn't work with the change in capitalization. This is in [polywavesynth_example] -- good catch; I'll fix it on the next release. 2) it's hard to adjust the ADSR sliders at low values. particularly for attack, it is important to be able to choose values around 20ms or 50ms. so i think a log, or exponential scaling would be better for the ADSR sliders. This is such an excellent idea, I implemented it immediately (changed the sliders to log). Not nearly so much shift-dragging is necessary now. You have to watch out for attack/decay/release values of less than 11 msecs. or so, though. They can sound very clicky (although this may actually be desired in certain circumstances). Again, this will be available on the next release; it's easy to change on your own, though, and it has no ill effects. 3) i had a look, and i can't figure out why, but it seems that the global gain is still somehow affecting the sound further up the chain. ie..when i adjust the global gain, the attack of the sound is also changing. still not sure where this is coming from, but maybe something connected to the adsr? I don't understand what you mean here...the gain slider on the [polywavesynth] UI is interacting with the attack? Are you sure it's not clipping - it's easy to clip with higher gain settings. The more notes you hold down, the higher the output, so for big polyphony, you have to bring the slider down a bit. If I'm totally misreading what you're saying here, let me know. 4) would be nice to have more control over the amount of panning. Like all the controls, it's available via OSC: [an lfo, or anything else you like] | [/example/pan/position $1 | (connect to the rightmost inlet of [polywavesynth]) Similarly, you can change the pan lagtime with a message like /example/pan/speed 0.8. The OSC implementation of [polywavesynth] (polygrainsynth works the same way) is here: http://www.pkstonemusic.com/polyWaveSynth.html#osc but yeah, there are lots of really good sounds possible with this, great synth!!! Thanks again for the excellent critique. Phil http://www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] [polygrainsynth] fixed
Hi again, I've just uploaded a fix for the grain pointer bug in [polygrainsynth] that showed up in the recent major release. Please grab v1.1 at: http://www.pkstonemusic.com/code/polygrainsynth.tgz Thanks for your patience, and enjoy. Phil Stone www.pkstonemusic.com ___ Pd-announce mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] [polygrainsynth] bug
Murphy's Law is upheld once more...I tested both synthesizers fairly carefully for almost a week before releasing them, but within hours of releasing, I've found a fairly major bug in [polygrainsynth]. This bug isn't fatal; you can make sound with the current [polygrainsynth]. The problem: pointer hop control doesn't work properly until after 'n' notes are played, where n equals your number of allocated voices. I know where the problem is, but don't have it fixed and tested yet. Expect an update soon. [polywavesynth] is fine, I think (knock on wood!). Phil Stone ___ Pd-announce mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Major updates to [polygrainsynth] and [polywavesynth]
Significant fixes and enhancements have been made to both [polygrainsynth] and [polywavesynth] (free polyphonic synthesizers for Pd). Please try these much-improved new versions. webpage: http://www.pkstonemusic.com/pd_code.html some improvisations made with these instruments: http://www.pkstonemusic.com/pubmusic.htm [polygrainsynth]: 2008-11-22 - v 1.0 * Added global toggle, which enables live output of global-capable parameters to all voices. * Added OSC-UI toggle, which enables the UI to follow OSC input. * Fixed many small bugs in indeterminacy (rand and drunken walk). * Fixed bug in pointer wrap function for negative pointer hops. * Eliminated pointer set slider and variable for anchoring. Anchored notes now start at the subsection beginning (for pointer hops greater than or equal to 0) or the subsection end (for pointer hops less than 0). * Eliminated rand/drunk switch to make rand and drunk controls less cumbersome. Now, a zero value in these parameters is used to switch them off. This has the added benefit of allowing complete independence between hop_size and grain_dur indeterminacy controls. * OSC nodes are all-lowercase now (e.g. /allNotesOff is now /allnotesoff). [polywavesynth]:m 2008-11-22 - v 4.0 * Added global toggle, which enables live output of global-capable parameters to all voices. * Added OSC-UI toggle, which enables the UI to follow OSC input. * Made 10 of the control parameters live i.e., global. * Fixed bug in noise wave table (only an eighth of it was initialized before!) * OSC nodes are all-lowercase now (e.g. /allNotesOff is now /allnotesoff). Phil Stone http://www.pkstonemusic.com ___ Pd-announce mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] nqpoly5, now with full loadbang support!
Ah, a preemptive enhancement, as it were. I vaguely wondered why I never had any trouble with [loadbang] and [polypoly]. Thanks, Frank. Phil Frank Barknecht wrote: Hallo, Phil Stone hat gesagt: // Phil Stone wrote: Can this fix be applied to [polypoly] as well? No. Because it already is. ;) Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] nqpoly5, now with full loadbang support!
Hi Frank, Can this fix be applied to [polypoly] as well? Phil Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I just did a quick hack job on Frank's improved nqpoly4 to make nqpoly5. It is very similar to the nqpoly4 but loadbangs work properly, thanks to the use of IOhannes' very useful [initbang]. Thanks for bringing this up again, but there is an easier and pure-Pd way to add the missing loadbang. I now checked in the fix to nqpoly4.pd which adds loadbang support by sending a final message loadbang to the poly-subpatch. I kept the inlets for compatibilitly. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [polywavesynth] and [polygrainsynth] bug fix
Hi again, If you use either of these synthesizers, please grab the latest. The previous versions moved gain to a global parameter. I should have known better; this causes glitches in already-sounding notes when presets change. I had a similar problem last year with [polywavesynth], but forgot about it. This is the tradeoff to using [poly] to manage voices; if you want the ability to change presets cleanly, most parameters (i.e., those stored to make up the preset) can only be changed on new attacks. I haven't thought of a way around this conundrum yet. At any rate, the latest versions fix this issue. Sorry for any inconvenience. This leads to the web pages and download links for both synthesizers: http://www.pkstonemusic.com/pd_code.html Phil Stone http://www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [polygrainsynth] minor update
This is a minor update; if you're using OSC with [polygrainsynth] (or ever plan to), you should pick it up. Some parts of the OSC tree were incomplete in the initial release of [polygrainsynth]. This has been rectified in version 0.2. webpage: http://www.pkstonemusic.com/polygrainsynth.html archive: http://www.pkstonemusic.com/code/polygrainsynth.tgz Phil Stone www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] new polyphonic granular synthesizer for Pd
Frank Barknecht wrote: Hallo, Phil Stone hat gesagt: // Phil Stone wrote: I'm pleased to announce the availability of [polygrainsynth], a polyphonic granular synthesizer built on the [a_grain] abstraction written by Jamie Bullock. Much like its older sibling [polywavesynth], [polygrainsynth] does automatic allocation and management of n voices, where n is limited only by your available processing power. That's very nice, and has exemplary documentation! Thank you, Frank. The object wouldn't have been possible without [polypoly] and several other of your excellent contributions. I didn't look at the internals yet, but it occured to me, that the dependency on OSC probably could be factored out (if you'd want to) by using Pd's standard [route]. The control messages would look like: (name) grain env atk 12 then and would include a tree of [route]s. To make that OSC-targetable one could use a separate abstraction. The disadvantage would be that one looses pattern matching. That's an intriguing idea. I *do* like the pattern matching, but it's not necessary at the interior level of the synthesizers. I wonder what the performance differences are, if any, between [routeOSC] and [route]? It's tempting, because with your recent work towards a vanilla-ready filter, it's getting more likely that [svf~] could be replaced with something non-external, and then my synthesizers could be completely external-free. Phil www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [import] verbosity
I'm using [import] on an abstraction (as discussed earlier); this abstraction does some automatic object instantiation (via [polypoly]) and each of the generated objects has an [import ...] in it. This leads to a barrage of console output, like: [import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local objectclass path libdir_loader: added 'cyclone' to the canvas-local objectclass path [import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local objectclass path libdir_loader: added 'cyclone' to the canvas-local objectclass path . . . (repeat for number of voices created by [polypoly]. A great enhancement for [import] would be a verbosity control! :-) Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
