Re: [PD] How to read I2C sensors?
Sounds great! I'll have to get the sensors first now (I was waiting to see if it would work at all) and see how far I'll get with it. Thanks Ingo Von: Ivica Bukvic [mailto:i...@vt.edu] Gesendet: Sonntag, 27. April 2014 23:27 An: Ingo Cc: Alexandros Drymonitis; pd-list Betreff: Re: AW: [PD] How to read I2C sensors? Check out also pd-l2ork k12 documentation where you can learn more about "lots of pots" RPi shield that gives you essentially 8 capacitive channels via the aforesaid mcp3008 d/a chip. This is what pd-l2ork essentially supports out of box. To access k12 mode start it with appropriate shortcut or simply type pd-l2ork -k12 HTH On Apr 27, 2014 3:52 PM, "Ingo" wrote: Thanks Ivica, I'll check out pd-l2ork. I might use a Raspberry Pi for that purpose anyway. I need some capacitive sensors that work without actually touching them. All I found was using I2C. Ingo Von: Ivica Bukvic [mailto:i...@vt.edu] Gesendet: Sonntag, 27. April 2014 20:38 An: Ingo Cc: Alexandros Drymonitis; pd-list Betreff: Re: [PD] How to read I2C sensors? I forget what i2c uses driverwise, but if it is spidev, in pd-l2ork you have disis_spi external that allows for reading data from mcp3008 8-channel ad converter. The external is specifically designed for Raspberry Pi build of pd-l2ork, but I don't see a reason why it could not be compiled for vanilla Pd as well. Perhaps it can be also used with your setup? On Apr 27, 2014 1:53 PM, "Ingo" wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ 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] How to read I2C sensors?
Thanks Ivica, I'll check out pd-l2ork. I might use a Raspberry Pi for that purpose anyway. I need some capacitive sensors that work without actually touching them. All I found was using I2C. Ingo Von: Ivica Bukvic [mailto:i...@vt.edu] Gesendet: Sonntag, 27. April 2014 20:38 An: Ingo Cc: Alexandros Drymonitis; pd-list Betreff: Re: [PD] How to read I2C sensors? I forget what i2c uses driverwise, but if it is spidev, in pd-l2ork you have disis_spi external that allows for reading data from mcp3008 8-channel ad converter. The external is specifically designed for Raspberry Pi build of pd-l2ork, but I don't see a reason why it could not be compiled for vanilla Pd as well. Perhaps it can be also used with your setup? On Apr 27, 2014 1:53 PM, "Ingo" wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ 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] How to read I2C sensors?
Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ 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] How to read I2C sensors?
I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Pd-extended for ARM - where to find the latest versions
I'm looking for the latest builds of Pd-extended for ARM (Cubietruck). I was checking "Index of /auto-build/latest" http://autobuild.puredata.info/auto-build/latest/ but there's nothing since 9 months. I'm looking for a version that would run on Lubuntu 12.04. Anything from 0.42.5 up should be working fine for me. I tried adding deb http://apt.puredata.info/releases precise main to /etc/apt/sources.list and did "apt-get update" It won't install from there using "apt-get install pd-extended". Any help or download link is appreciated! Thanks Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] WG: Inverse bandpass filter
You could send the original signal in parallel and invert the phase by multiplying with -1. You might have to delay the original signal in case that the processed signal gets also delayed by one or more blocks. Ingo ___ > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > AP Vague > Gesendet: Freitag, 18. April 2014 18:49 > An: pd-list@iem.at > Betreff: [PD] Inverse bandpass filter > > Is there a simple way to make [bp~] or [vcf~] have an inverse function? To > filter out, rather than pass a changing frequency value. Is the easiest > way to do this with a combination of [lop~] and [hip~]? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended with Cubietruck (Cubieboard3)
Thanks, Felix! I just got the Cubietruck and was wondering if anybody had been successful running Pd-extended on it so far. I guess the specific questions will arise once I'm at the point where I'll try to install (or run) Pd. Knowing that a certain OS would work better than others might have saved some time ... Since I had been running everything on Ubuntu so far I guess I'll go with the provided image of Lubuntu 12.04 LTS at first and see what will happen. If that will give me a hard time I'll try Cubian next. I hope the Ubuntu version of Pd-extended will run on Lubuntu the same as on Ubuntu. I don't know the exact differences between the two (except for the different Desktop). I guess I'll find out soon ... Ingo > > Von: showlabor.felixhom...@gmail.com > [mailto:showlabor.felixhom...@gmail.com] Im Auftrag von Felix Homann > Gesendet: Dienstag, 25. März 2014 12:29 > An: Ingo > Betreff: Re: [PD] Pd-extended with Cubietruck (Cubieboard3) > > 2014-03-25 11:44 GMT+01:00 Ingo : > > Has anyone tried the Cubietruck (aka Cubieboard3) with Pd-extended? I'm playing around with a CubieTruck at the moment but haven't tried Pd yet. Could you be more specific about what you would want to know? I would (try to) install Pd-extended and answer your questions then (in the next couple of days). > Seems to be one of the more powerful arm boards around with some great > features (see below). Yes, it's way ahead of the raspi performance wise. > If yes, what would be the best linux version for running it? I'm running it on "Cubian" at the moment which is their Debian derivative. Unfortunately it's running on a 3.4.75 kernel by default which is missing lots of USB audio improvements. I haven't found the time yet to try installing a more recent kernel. Regards, Felix ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Pd-extended with Cubietruck (Cubieboard3)
Hi everybody! Has anyone tried the Cubietruck (aka Cubieboard3) with Pd-extended? Seems to be one of the more powerful arm boards around with some great features (see below). If yes, what would be the best linux version for running it? Ingo Cubietruck Kit - Dual Core Single-board Computer Features: Allwinner Tech A20 SOC SATA supported 54 extended pins Built-in HDMI/ VGA display interface Built-in WIFI+BT module 2GB DDR3 RAM Built-in IR receiver SPDIF audio interface Specifications: Allwinner Tech SOC A20 ARMR CortexT-A7 Dual-Core ARMR Mali400 MP2 Complies with OpenGL ES 2.0/1.1 2GB DDR3@480MHz HDMI&VGA 1080P display output on-board 10M/100M/1G Ethernet WIFI + BT wireless connection with antenna on-board SATA 2.0 interface support 2.5' HDD (for 3.5' HDD, only need another 12V power input) Storage solution NAND + MicroSD 2 x USB HOST, 1 x OTG, 1 x SPDIF, 1 x IR, 4 x LEDs, 1 x Headphone, 3 x Keys Power DC5V@2.5A with HDD support Li-battery & RTC 54 extended pins including I2S, I2C, SPI, CVBS, LRADC x2,UART, PS2, PWM x2, TS/CSI, IRDA, LINEIN&FMIN&MICIN, TVIN x4 with 2.0 pitch connectors PCB size 11cm *8cm*1.4mm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tannhauser Pure Data compiler
Yeah, I had found that but nothing else except that the "OWL", a programmable effects pedal, can use Pd patches after compiling them to C with Tannhauser. Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Pierre Massat Gesendet: Montag, 17. März 2014 14:12 An: Simon Wise Cc: pd-list Betreff: Re: [PD] Tannhauser Pure Data compiler Not much information on either page... Pierre. 2014-03-17 14:06 GMT+01:00 Simon Wise : On 17/03/14 23:26, Ingo wrote: I just found out about the "Tannhäuser Pure Data compiler". Does anybody know who makes it or where to get this compiler? Thanks! Ingo google took me here ... https://www.hackerleague.org/hackathons/automatic-music-hackathon/hacks/tann hauser-a-c-compiler-for-pure-data perhaps Martin Roth is your man https://www.hackerleague.org/users/mhroth ___ 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] Tannhauser Pure Data compiler
I just found out about the "Tannhäuser Pure Data compiler". Does anybody know who makes it or where to get this compiler? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
Roman, are you using MIDI in theory or "real life"? "Jitter" is MIDI's "alias name". In practice MIDI data is being reduced as much as possible to avoid overloading the MIDI bus and in return causing serious timing problems or even missing data. Since I would not expect this signal to be the only one through the MIDI interface I would actually reduce the data on fast changes even drastically more. All (decent) MIDI receiving devices interpolate between the values in order to avoid zipper noise. I see your point - in fact I had the same thought that you had at first! I dropped it right away. Working on a daily basis with MIDI I know that this is a waste of time. Actually: I would add a [speedlim 5] to reduce data further and you still wouldn't hear anything unusual. That reminds me a little of people asking for 14-bit pitchbend. It would take about 11 seconds to move the pitchbend wheel on a keyboard from the bottom to the top. Even a 7-bit pitchbend takes more that 80 ms sending all values. It's impossible to play music with a precise timing like this! In practice a very fast volume change going from 0 - 127 usually gets reduced to 3-5 numbers in order to allow additional controllers like pitchbend and aftertouch to be sent at the same time and still keep the note on jitter within a range of maybe 3-8 ms (plus the jitter of the interface itself). And BTW - why would "random" need extra precision? Doesn't the word random say it all? Another neglected thing is the curve that the data change should have. That would obviously require some extra calculation. I don't remember reading anything about that in the original posting, though. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Roman Haefeli > Gesendet: Montag, 24. Februar 2014 14:14 > An: pd-list@iem.at > Betreff: Re: [PD] smooth random numbers > > On Mon, 2014-02-24 at 13:35 +0100, Ingo wrote: > > Sorry, > > > > forgot ta add [change -1] after the [i]. > > > > I thought this was meant to be used with a MIDI signal - maybe I got > that > > wrong? > > Yes, it is. I'm nit-picking here. The patch you posted before also > works, even without the [change -1]. But even adding the [change -1] > doesn't address the issues I mentioned. On a fast ramp, it still misses > some values and it still suffers from jitter. It's only details I'm > talking about here, yes, but since you decided to remove the features > from my version, I hoped to be able to illustrate them with words. > > Roman > > > > > > > -Ursprüngliche Nachricht- > > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > > Roman Haefeli > > > Gesendet: Montag, 24. Februar 2014 10:34 > > > An: pd-list@iem.at > > > Betreff: Re: [PD] smooth random numbers > > > > > > On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: > > > > Starting from Roman's patch I would probably do it like the attached > > > patch. > > > > > > Many ways might solve a certain problem and in Pd those many ways can > > > often be divided into a "subtractive" approach - more than necessary > is > > > generated and the overhead is filtered out afterwards - and an > > > "additive" approach - exactly the data needed is generated. > > > > > > I believe you totally missed the point why I chose the latter here. > > > Using a constant time grain for [line] generates too much data for > slow > > > ramps, leading to many duplicates. Attach a print to our patch and > > > you'll see. At the same time it misses some integer numbers for fast > > > ramps. Also, by having a fixed time grain the result looks like a > > > resampled ramp (which it basically is), which means it is jittery and > > > doesn't emulate a steady movement of the fader. > > > > > > > > > Roman > > > > > > > > > > > > ___ > > > 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] smooth random numbers
Sorry, forgot ta add [change -1] after the [i]. I thought this was meant to be used with a MIDI signal - maybe I got that wrong? Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Roman Haefeli > Gesendet: Montag, 24. Februar 2014 10:34 > An: pd-list@iem.at > Betreff: Re: [PD] smooth random numbers > > On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: > > Starting from Roman's patch I would probably do it like the attached > patch. > > Many ways might solve a certain problem and in Pd those many ways can > often be divided into a "subtractive" approach - more than necessary is > generated and the overhead is filtered out afterwards - and an > "additive" approach - exactly the data needed is generated. > > I believe you totally missed the point why I chose the latter here. > Using a constant time grain for [line] generates too much data for slow > ramps, leading to many duplicates. Attach a print to our patch and > you'll see. At the same time it misses some integer numbers for fast > ramps. Also, by having a fixed time grain the result looks like a > resampled ramp (which it basically is), which means it is jittery and > doesn't emulate a steady movement of the fader. > > > Roman > > > > ___ > 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] smooth random numbers
This one can be retriggered to change speed anytime. Ingo #N canvas 988 0 345 419 10; #X obj 71 135 random 128; #X obj 71 108 metro 5000; #X obj 71 90 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 189 line; #X obj 71 209 i; #X obj 71 162 pack f 5000; #X msg 254 32 5000; #X obj 161 384 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 365 5 0 0 0 - - -; #X obj 71 231 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 4400 1; #X floatatom 71 365 5 0 0 0 - - -; #X text 197 363 target; #X text 287 20 time; #X obj 14 73 loadbang; #X msg 253 10 1000; #X obj 181 69 t b f b; #X msg 134 19 0; #X msg 134 39 1; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 15 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 15 0; #X connect 15 0 17 0; #X connect 15 1 1 1; #X connect 15 1 5 1; #X connect 15 2 16 0; #X connect 16 0 2 0; #X connect 17 0 2 0; > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von Ingo > Gesendet: Sonntag, 23. Februar 2014 04:21 > An: 'Roman Haefeli'; pd-list@iem.at > Betreff: Re: [PD] smooth random numbers > > Starting from Roman's patch I would probably do it like the attached > patch. > > Ingo > > > #N canvas 988 0 286 367 10; > #X obj 71 76 random 128; > #X obj 71 49 metro 5000; > #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; > #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg > 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 > 10 -262144 > -1 -1; > #X floatatom 161 306 5 0 0 0 - - -; > #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 > -1 -1 900 1; > #X floatatom 71 306 5 0 0 0 - - -; > #X text 197 304 target; > #X text 217 20 time; > #X obj 14 14 loadbang; > #X msg 183 10 1000; > #X connect 0 0 5 0; > #X connect 0 0 8 0; > #X connect 1 0 0 0; > #X connect 2 0 1 0; > #X connect 3 0 4 0; > #X connect 4 0 9 0; > #X connect 5 0 3 0; > #X connect 6 0 1 1; > #X connect 6 0 5 1; > #X connect 8 0 7 0; > #X connect 9 0 10 0; > #X connect 13 0 2 0; > #X connect 14 0 1 1; > #X connect 14 0 5 1; > > > > > -Ursprüngliche Nachricht- > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > Roman Haefeli > > Gesendet: Samstag, 22. Februar 2014 23:27 > > An: pd-list@iem.at > > Betreff: Re: [PD] smooth random numbers > > > > On Sam, 2014-02-22 at 21:54 +, Pagano, Patrick wrote: > > > > > > > > I would like to start creating random midi values from 0-127 and pick > > > each number say every 5 second and have each random number then flow > > > to the next smoothly. so if say the first number is 60 and the second > > > is 85, the data stream would flow from 60, 61, 62 63.until it > > > reached 85 and then from 85 smoothly to the next random selection. > > > > See attached patch. > > > > > I have not had the luck i was hoping with Vline, someone suggested an > > > array but i am hoping someone might share some math or abstraction so > > > i can get a handle on how to implement it > > > > Though one could do it with [vline~ ], it is probably cheaper (cpu-wise) > > and actually simpler with [line]. The trick is to adjust the time grain > > to make it output only integer numbers. > > > > Roman > > #N canvas 988 0 345 419 10; #X obj 71 135 random 128; #X obj 71 108 metro 5000; #X obj 71 90 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 189 line; #X obj 71 209 i; #X obj 71 162 pack f 5000; #X msg 254 32 5000; #X obj 161 384 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 365 5 0 0 0 - - -; #X obj 71 231 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 4400 1; #X floatatom 71 365 5 0 0 0 - - -; #X text 197 363 target; #X text 287 20 time; #X obj 14 73 loadbang; #X msg 253 10 1000; #X obj 181 69 t b f b; #X msg 134 19 0; #X msg 134 39 1; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 15 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 15 0; #X connect 15 0 17 0; #X connect 15 1 1 1; #X connect 15 1 5 1; #X connect 15 2 16 0; #X connect 16 0 2 0; #X connect 17 0 2 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
Starting from Roman's patch I would probably do it like the attached patch. Ingo #N canvas 988 0 286 367 10; #X obj 71 76 random 128; #X obj 71 49 metro 5000; #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 306 5 0 0 0 - - -; #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 900 1; #X floatatom 71 306 5 0 0 0 - - -; #X text 197 304 target; #X text 217 20 time; #X obj 14 14 loadbang; #X msg 183 10 1000; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 1 1; #X connect 6 0 5 1; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 1 1; #X connect 14 0 5 1; > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Roman Haefeli > Gesendet: Samstag, 22. Februar 2014 23:27 > An: pd-list@iem.at > Betreff: Re: [PD] smooth random numbers > > On Sam, 2014-02-22 at 21:54 +, Pagano, Patrick wrote: > > > > > I would like to start creating random midi values from 0-127 and pick > > each number say every 5 second and have each random number then flow > > to the next smoothly. so if say the first number is 60 and the second > > is 85, the data stream would flow from 60, 61, 62 63.until it > > reached 85 and then from 85 smoothly to the next random selection. > > See attached patch. > > > I have not had the luck i was hoping with Vline, someone suggested an > > array but i am hoping someone might share some math or abstraction so > > i can get a handle on how to implement it > > Though one could do it with [vline~ ], it is probably cheaper (cpu-wise) > and actually simpler with [line]. The trick is to adjust the time grain > to make it output only integer numbers. > > Roman > #N canvas 988 0 286 367 10; #X obj 71 76 random 128; #X obj 71 49 metro 5000; #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 306 5 0 0 0 - - -; #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 900 1; #X floatatom 71 306 5 0 0 0 - - -; #X text 197 304 target; #X text 217 20 time; #X obj 14 14 loadbang; #X msg 183 10 1000; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 1 1; #X connect 6 0 5 1; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 1 1; #X connect 14 0 5 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino + Standard Firmata + Arduino MIDI interface
Thanks! I've looked around and there is some code out there. Looks like the MIDI In which is what I mostly need definitely needs some electronic parts in order to be working. There is some code that I will test but I'm still note sure if it will conflict with the standard firmata. I guess I'll get the parts and start testing with the code that I found. Ingo Von: José Luis Santorcuato Tapia [mailto:santorcuat...@gmail.com] Gesendet: Donnerstag, 9. Januar 2014 18:25 An: Ingo Scherzinger Betreff: Re: [PD] Arduino + Standard Firmata + Arduino MIDI interface Hi, is not necessary...you can googling a lot of midi projets with arduino...you could use a 5 pins midi connector...but i think yes...if you can asign properly data and pins...Cheap and easy... Best José El ene 9, 2014 7:13 AM, "Ingo" escribió: Hi, I was wondering if I could use an Arduino as a MIDI interface while running the standard firmata. Does anybody do this? Can the additional software simply be added to the firmata or is it necessary to edit the firmata for doing this. Does the Arduino need extra parts like opto-couplers? Or is that stuff already on the board? (I'm using a Duemilanove with Ubuntu) I would appreciate if anybody could point me in a direction where I could find some working MIDI software that can be added to the firmata. Thanks! Ingo ___ 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] Arduino + Standard Firmata + Arduino MIDI interface
Hi, I was wondering if I could use an Arduino as a MIDI interface while running the standard firmata. Does anybody do this? Can the additional software simply be added to the firmata or is it necessary to edit the firmata for doing this. Does the Arduino need extra parts like opto-couplers? Or is that stuff already on the board? (I'm using a Duemilanove with Ubuntu) I would appreciate if anybody could point me in a direction where I could find some working MIDI software that can be added to the firmata. Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM causes soung glitches
I have to fully agree with Iohannes. I have a huge patch that works perfectly the same with and without GEM running as a second patch. However, recently I had to change the hardware and I'm having problems now. This is neither a problem with GEM nor with the patch. It's a hardware driver problem. The proprietary ATI drivers were not working with this mainboard so I used the Ubuntu drivers which are no good - and I get drop outs much earlier than before. The more complex the patch gets the more important it is to have a perfectly working system and hardware. There is nothing you can fix in GEM if you have bad drivers or a badly designed patch. There are already a number of ways to set priorities in the system e.g. by setting up a low latency or realtime system with the best options, the Pd startup flags as well as patch design. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Luiz Naveda Gesendet: Samstag, 28. Dezember 2013 22:34 An: IOhannes m zmölnig Cc: pd-list@iem.at Betreff: Re: [PD] GEM causes soung glitches Iohannes, I am very sad to listen these words from you. I am just trying to point to a problem that I feel is important: making sound and work with gem causes glitches in several scenarios. It is a main problem for me and for some people I know. I accept that you think I am not a professional as you are and I also accept that I have all sort of design problems. No problem. But we have a problem here. I am just trying to wave the priority. I cant help solving the problem directly. My programming skills are not so good. But if you want I can do other tasks, try to raise money, I dont know. How do I start? I would like to ask you, in a very kind way and very friendly. Try not to reply posts like that suggesting that I am not professional or etc. It makes people afraid of contributing. Please, call me anything but let people express their opinions without being hit by emails like that. I am saying this waiving a white flag :-) Plese! All the best Luiz On Sat, Dec 28, 2013 at 8:49 AM, IOhannes m zmölnig wrote: On 2013-12-28 02:56, Luiz Naveda wrote: > This workaround doesn't solve the problem. When you have to deal with > messages, debugs and all sort of problems in the communication of instances > it just start the wave of problems. most likely, you have a serious design problem. For newbies working with simple patches > it is a frustration. For people working professionally in complex patches > it is a hell. then you do you have a serious design problem. > > I think it is a annoying, important and bizarre problem for a software > aimed at multimedia computing. The last time I had to deal with this > rarely documented problem made me consider switch to other platforms. I > wish someone could make it a high priority request for the PD developers. > the fact that it is a "rarely documented problem" makes me think that the priority need not be as high as you suggest. in the meantime, raise the audio buffer of Pd. (and get yourself a decent gfx card with some proprietary (shudder) drivers). having said that, there is certainly loads of things to improve. since you seem to be "working professionally in complex" scenarios, i would like to invite you to help solving the problem (in a way that doesn't break everything platform X) fgmdsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Luiz Naveda _ - PhD researcher http://www.ipem.ugent.be/samba - Director SysMus09 http://www.ipem.ugent.be/sysmus09 IPEM - Institute for Psychoacoustics and Electronic Music Ghent University Office: + 32 9 264 4127 Blandijnberg 2 Ghent, B-9000 Belgium ^v^ ^v^ ^v^ ^~^~^~^~^~^~^~^~~^~~^~~^~^~^~~~^^~^ ^~^~^~^~^~^~^~^~^~^~~^~~^~~^~^~^~~~^~~~ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] realtime MIDI on Windows - best practices for efficiency?
3 things come to my mind spontaneously: 1) use a good sound card with good asio drivers (if you don't do already) 2) raise the latency a little bit 3) eliminate graphical objects like number boxes, sliders, etc. If you use [mapping/resample] I would suggest adding [change] afterwards to avoid constant data to be sent or use [speedlim] which does the same thing. Ingo [PD] realtime MIDI on Windows - best practices for efficiency? I have a big patch I use for realtime manipulation of live sound inputs. Often when adjusting pots and sliders on a USB MIDI controller, I get audio dropouts. I've tried putting all of the MIDI objects in a separate patch running in another instance of PD, polling the inputs at intervals using [mapping/resample] to reduce the amount of data being sent, and sending the data over OSC to the main patch. I've killed as many other processes as possible. And I still get dropouts. What could I be doing wrong? This is 0.43.4-extended on Windows 7. Thanks, Joe -- www.joenewlin.net www.twitter.com/joe_newlin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] USB power off from [shell] for eliminating MIDI interfaceproblems
I have tried echo on > /sys/bus/usb/devices/usb1/power/level # turn on echo suspend > /sys/bus/usb/devices/usb1/power/level # turn off with different devices (like 4-2 which is the MIDI interface) and I'm always getting "invalid argument" when I try to use "suspend". Any ideas? Ingo > A while ago a MIDI interface problem came up here that nobody seemed to > really know about: > > All the sudden huge delays in the range of one or more seconds started to > happen and then the interface sometimes possibly started playing notes, > etc. > on its own. > I had experienced this quite a few times with Pd on Windows and Linux and > already way back (about 25 years ago) with my Akai MPC60 drum sequencer. > > I finally found out what causes it. > When starting the computer the interface gets powered up as well before > the > system is ready to receive any information coming from the interface. > Therefor the interface keeps every input on the MIDI side in a buffer > until > it can transmit it to the USB port. > > From time to time the buffer gets completely overloaded during startup > when > receiving too much MIDI what in return makes the interface go nuts! The > only > way to reset it is to disconnect it from power. > > > Now here is my question: > > Does anybody know how I can power off a USB port (probably using [shell]) > to > do a reset (USB power off - USB power on) while or after loading the > patch? > > I'm on Ubuntu Natty. > > Thanks > Ingo > > > ___ > 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] USB power off from [shell] for eliminating MIDI interface problems
A while ago a MIDI interface problem came up here that nobody seemed to really know about: All the sudden huge delays in the range of one or more seconds started to happen and then the interface sometimes possibly started playing notes, etc. on its own. I had experienced this quite a few times with Pd on Windows and Linux and already way back (about 25 years ago) with my Akai MPC60 drum sequencer. I finally found out what causes it. When starting the computer the interface gets powered up as well before the system is ready to receive any information coming from the interface. Therefor the interface keeps every input on the MIDI side in a buffer until it can transmit it to the USB port. >From time to time the buffer gets completely overloaded during startup when receiving too much MIDI what in return makes the interface go nuts! The only way to reset it is to disconnect it from power. Now here is my question: Does anybody know how I can power off a USB port (probably using [shell]) to do a reset (USB power off - USB power on) while or after loading the patch? I'm on Ubuntu Natty. Thanks Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] $1 inside a message is not saving data ?
A message box $1 doesn't save the last value like other objects do. Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von ?? Gesendet: Sonntag, 6. Oktober 2013 13:13 An: pd-list@iem.at Betreff: [PD] $1 inside a message is not saving data ? Dear PD-list . I found that in PD-extended 42.5 - the $1 inside a message is not saving data. Is it a bug ? see patch below. \\ #N canvas 939 165 700 300 10; #X msg 139 127 0 \$1; #X obj 139 175 print; #X floatatom 111 74 5 0 0 0 - - -; #X obj 181 73 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 117 48 1; #X text 183 52 2; #X text 216 112 Why message is not saving data in \$1 ?; #X connect 0 0 1 0; #X connect 2 0 0 0; #X connect 3 0 0 0; \ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is there a way to turn on or off the filters in pd
You could just bypass them by using [demux~] or simply multiplying the direct signal and effect signal with 1 or 0. Alternatively - if you want to bypass processing altogether you could place each eq band, filter and compressor in a separate abstractions and turn them on and off with [switch~] while bypassing the signal if the effect is off. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Luca Mani Gesendet: Samstag, 14. September 2013 20:49 An: pd-list@iem.at Betreff: [PD] is there a way to turn on or off the filters in pd Hello, I'm building a channel strip in which there are 2 filters 3 eqs and one compressor. I would like to be able to turn them on or off one by one. Is there any kind of switch in pd which allows me to do that ? Thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] send message to current pd-window
Thanks! I'll take a look at those two. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Simon Wise > Gesendet: Donnerstag, 29. August 2013 09:36 > An: pd-list@iem.at > Betreff: Re: [PD] send message to current pd-window > > On 29/08/13 14:57, Ingo wrote: > > I was kind of hoping to find a simple and existing solution for globally > > sending hid inputs to the current Pd-patch / subpatch / window inside of > Pd. > > > > Since I need this only for speeding up programming I found an external > > solution "btnx" to reprogram the mouse buttons for sending key commands. > > That does the trick for me. > > xbindkeys is a quite useful general tool for this kind of thing, mapping > key or > mouse combinations to commands, also if you want there is a scheme option > for > more intricate mappings of sequences etc. nice for configuring keystroke > and > mouse button independently of all the annoying desktop gui stuff. > > or triggerhappy (thd) which is similar but outside X > > Simon > > > > ___ > 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] send message to current pd-window
I was kind of hoping to find a simple and existing solution for globally sending hid inputs to the current Pd-patch / subpatch / window inside of Pd. Since I need this only for speeding up programming I found an external solution "btnx" to reprogram the mouse buttons for sending key commands. That does the trick for me. Thanks anyway Ingo > -Ursprüngliche Nachricht- > Von: Jonathan Wilkes [mailto:jancs...@yahoo.com] > Gesendet: Mittwoch, 28. August 2013 18:09 > An: Ingo > Betreff: Re: AW: [PD] send message to current pd-window > > On 08/28/2013 12:25 AM, Ingo wrote: > > Thanks for the suggestion! > > > > [active] can only tell if the current window has the focus or not. > > > > [active] together with [window_name] can actually send the current > window > > name as soon as it gets activated but that would require placing an > > abstraction in every single patch and subpatch. I have a huge amount of > > abstractions and subpatches so that is kind of out of the question. > > > > Somehow Pd has to keep track of which window is currently opened and > active. > > Isn't there a way to get that window / sub patch name without sending it > > from the actual subpatch itself? > > You could make a gui-plugin to do it. Check the tcl/tk documentation > and the gui-rewrite plugin. I'm sure tcl/tk has a way to bind to such > an event (or a way to create one if it doesn't). > > -Jonathan > > > > > Alternatively - is there a way to send letters or ASCII characters from > > within Pd to Pd? Like CTRL + E for edit mode or anything else that can > be > > done by QWERTY key commands? > > > > Ingo > > > > > >> -Ursprüngliche Nachricht- > >> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > >> Jonathan Wilkes > >> Gesendet: Dienstag, 27. August 2013 17:44 > >> An: pd-list@iem.at > >> Betreff: Re: [PD] send message to current pd-window > >> > >> On 08/27/2013 07:00 AM, Ingo wrote: > >>> I'trying to use a mouse button to toggle between edit mode on off. > >>> I'm using [hid] to get the mouse button and I can send the message to > a > >>> specified window name. > >>> > >>> But how can I send it to the current window that I am working in? > >>> > >>> What would I have to use instead of "windowname"? > >>> > >>> [s pd-"windowname"] > >> [s pd-filename.pd] > >> > >> or > >> > >> [s pd-subpatchname] > >> > >> To automatically figure out which window has the focus, I think > >> there's a cyclone object that does that. Maybe [active] ? > >> > >>> Thanks, Ingo > >>> > >>> > >>> ___ > >>> 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] send message to current pd-window
Thanks for the suggestion! [active] can only tell if the current window has the focus or not. [active] together with [window_name] can actually send the current window name as soon as it gets activated but that would require placing an abstraction in every single patch and subpatch. I have a huge amount of abstractions and subpatches so that is kind of out of the question. Somehow Pd has to keep track of which window is currently opened and active. Isn't there a way to get that window / sub patch name without sending it from the actual subpatch itself? Alternatively - is there a way to send letters or ASCII characters from within Pd to Pd? Like CTRL + E for edit mode or anything else that can be done by QWERTY key commands? Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Jonathan Wilkes > Gesendet: Dienstag, 27. August 2013 17:44 > An: pd-list@iem.at > Betreff: Re: [PD] send message to current pd-window > > On 08/27/2013 07:00 AM, Ingo wrote: > > I'trying to use a mouse button to toggle between edit mode on off. > > I'm using [hid] to get the mouse button and I can send the message to a > > specified window name. > > > > But how can I send it to the current window that I am working in? > > > > What would I have to use instead of "windowname"? > > > > [s pd-"windowname"] > > [s pd-filename.pd] > > or > > [s pd-subpatchname] > > To automatically figure out which window has the focus, I think > there's a cyclone object that does that. Maybe [active] ? > > > > > Thanks, Ingo > > > > > > ___ > > 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] send message to current pd-window
I'trying to use a mouse button to toggle between edit mode on off. I'm using [hid] to get the mouse button and I can send the message to a specified window name. But how can I send it to the current window that I am working in? What would I have to use instead of "windowname"? [s pd-"windowname"] Thanks, Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] changing message value in real time
Maybe that is what you need? Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Dmitry Morozov Gesendet: Montag, 17. Juni 2013 12:34 An: pd-list@iem.at Betreff: [PD] changing message value in real time hi to everyone! sorry for dumb question is it possible to change message value in realtime? I need to control few objects with the same value. In an attached patch I have 3 time values with 1000ms, but I need to change them realtime with slider for example - is it possible? thanks! dmitry #N canvas 804 244 508 516 10; #X obj 152 288 line; #X floatatom 152 305 5 0 0 0 - - -; #X obj 152 338 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 0 1; #X obj 155 124 t b b; #X obj 212 219 delay 1000; #X msg 52 190 64 2000; #X msg 152 258 0 2000; #X msg 269 112 2000; #X msg 69 102 1000; #X msg 52 142 set 127 1000; #X msg 222 152 set 64 2000; #X msg 266 62 set 0 2000; #X msg 96 62 set 0 1000; #X obj 35 32 t b b b b; #X obj 35 14 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 205 14 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 205 32 t b b b b; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 3 0 5 0; #X connect 3 1 4 0; #X connect 4 0 6 0; #X connect 5 0 0 0; #X connect 6 0 0 0; #X connect 7 0 4 1; #X connect 8 0 4 1; #X connect 9 0 5 0; #X connect 10 0 5 0; #X connect 11 0 6 0; #X connect 12 0 6 0; #X connect 13 0 3 0; #X connect 13 1 9 0; #X connect 13 2 8 0; #X connect 13 3 12 0; #X connect 14 0 13 0; #X connect 15 0 16 0; #X connect 16 0 3 0; #X connect 16 1 10 0; #X connect 16 2 7 0; #X connect 16 3 11 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Forwarding serial data through an Arduino (with firmata) to a serial display
Thanks! I'll have a look at the SoftwareSerial library. > You also need a TTL-to-RS232C voltage converter between the Arduino and > display. The serial converter of the display takes already care of that. > It is probably much simpler to use a separate USB to serial adapter. > Those work out of the box with Ubuntu and you only have to change the > serial port name in your patch. Yes, that works fine but it mixes up the port number of the arduino and the serial adapter. I can't get the two to be assigned to the same port number each time Pd starts. They both show up as /dev/ttyUSB0 or /dev/ttyUSB1 on the [comport]. It also would be cleaner with less cables to have the arduino taking care of the serial data transfer. If I can't get that to work I'll have to use a serial adapter and find a good way to distinguish the two automatically. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Fred Jan Kraan > Gesendet: Mittwoch, 5. Juni 2013 19:18 > An: pd-list@iem.at > Betreff: Re: [PD] Forwarding serial data through an Arduino (with firmata) > to a serial display > > On 2013-06-05 14:24, Ingo wrote: > > Hi everybody! > > > > I am dealing with the problem that I have changed to a new mainboard > which > > doesn't have a serial port anymore. I'm on Ubuntu Natty. > > > > I used to send LCD display data to my remote on the normal serial port > using > > [comport]. The display itself has a serial interface. The remote uses a > > separate cable and [comport] for USB going to the arduino. > > > > Is it possible to transfer the serial data for the display through the > > arduino using the arduinos serial out to feed the display (with a baud > rate > > of 19200) ? > > > > I still need to use firmata for all other arduino stuff. > > So it should be like an addon to firmata. Or is this already possible > with > > the current firmata? > > > > If anybody has done this before I'd appreciate any help! > > I did some Arduino programming but not much with Firmata. > > It is possible, but it probably means you have to create your own > firmata sketch which includes the SoftwareSerial library. With an > Arduino with more serial ports, like the Mega2560 or Leonardo, you won't > need SoftwareSerial but still a custom Firmata. You also need a > TTL-to-RS232C voltage converter between the Arduino and display. > > It is probably much simpler to use a separate USB to serial adapter. > Those work out of the box with Ubuntu and you only have to change the > serial port name in your patch. > > > > Ingo > > Greetings, > > Fred Jan > > > > > > ___ > > 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] Forwarding serial data through an Arduino (with firmata) to a serial display
Hi everybody! I am dealing with the problem that I have changed to a new mainboard which doesn't have a serial port anymore. I'm on Ubuntu Natty. I used to send LCD display data to my remote on the normal serial port using [comport]. The display itself has a serial interface. The remote uses a separate cable and [comport] for USB going to the arduino. Is it possible to transfer the serial data for the display through the arduino using the arduinos serial out to feed the display (with a baud rate of 19200) ? I still need to use firmata for all other arduino stuff. So it should be like an addon to firmata. Or is this already possible with the current firmata? If anybody has done this before I'd appreciate any help! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Last Ubuntu version for Pd-extended 0.42.5
Let's put it in another way: is anybody running Pd-extended 0.42.5 on ubuntu 12.04 "precise"? Thanks Ingo > Betreff: [PD] Last Ubuntu version for Pd-extended 0.42.5 > > Hi! > > I'm running into a "new hardware" problem. My old system won't boot up > anymore with the new mainboard (amd fm2 chipset) but I want to stay > backward > compatible with the old hardware (am3 chipset). > > Does anybody know how long Pd-extended 0.42.5 was supported (i.e. to which > Ubuntu version) and where I can download that Pd-extended version (Ubuntu > i386 32 bit). > > A kernel update to one of the latest kernels like "raring" didn't work. > > Any help is appreciated! > > Thanks a lot! > Ingo > > > ___ > 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] Last Ubuntu version for Pd-extended 0.42.5
Hi! I'm running into a "new hardware" problem. My old system won't boot up anymore with the new mainboard (amd fm2 chipset) but I want to stay backward compatible with the old hardware (am3 chipset). Does anybody know how long Pd-extended 0.42.5 was supported (i.e. to which Ubuntu version) and where I can download that Pd-extended version (Ubuntu i386 32 bit). A kernel update to one of the latest kernels like "raring" didn't work. Any help is appreciated! Thanks a lot! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] "musical" timing, something like Max´s "metrical timing Transport" and [metro 16n]
Sorry I just noticed this shoul have been [midirealtimein] instead of [midiin]. Like this: [midirealtimein] | [sel 248] | [t b b] | | [timer] | [/ 4] Ingo > I don't have an exact plan on how to do this without spending a lot of > time > finding the most effective way for getting the accurate sample positions. > Maybe someone else has done that before. > > However, in your particular case I would simply use midi clock from > Ableton > to sync the two. That looks much easier. > > If your timing resolution is a maximum of 24 clocks per quarter note you > don't have to do anything. Just trigger the Pd sequencer steps from the > incoming midi clock. > > If you need a higer resolution you could simply use a [timer], [cputime] > or > [realtime] to check the time from one clock to another and use that for > subdividing for higher resolutions. > > As in the example below with 120 BPM and 500 ms per beat each midi clock > would have a resolution of 20.8... ms (500 / 24). Using a resolution > of > 96 / quarter note you would have to divide this by 4 which comes out to > 5.208333... ms. > > (BTW, you can see already from the 5.208333... ms that the time you > would have to enter for the metro would render a tempo that is slightly > off!) > > Syncing to midi clock would allow you to follow the tempo that is > programmed > in Ableton without having to worry about calculating the duration of each > clock. > > In Pd use [midiin] and [route] or [select] to get F8 (hex) = 248 > (decimal). > This is how to get the clock time of 96 clocks / quarter note: > > [midiin] > | > [sel 248] > | > [t b b] > | | > [timer] > | > [/ 4] > > Don't start interpolation until the second incoming clock (or provide a > usable value before the first clock is coming in). I.e. when starting jump > from 0 to 4 and then increase by 1. > > Check out the midi specs for additional features like song pointer or midi > timecode (which has nothing to do with midi clock), etc. > > > Ingo > > > > > Thanks Ingo, I must do the testing. In fact Im recordind de midiout to > > Ableton Live. > > "recalculating the position from time to time and resyncing to the > > absolute sample position might be necessary" how can I do this? > > did you see my patch? im working with something lika a "master" metro > > and a couple of "slave" metro objetcs that control a particular > > sequence. > > > > > > 2013/3/21 Ingo : > > > I would assume that the rounding errors of metro would make the > > > tempo > > drift > > > after a while - depending on the speed. > > > > > > Using the sample rate would be more accurate. > > > > > > In order to insure that the rounding errors are not influencing the > > > the position after a long time recalculating the position from time > > > to time > > and > > > resyncing to the absolute sample position might be necessary. > > > > > > However, such an accuracy would only be needed if the music is to be > > synced > > > to anything external like a DAW, I guess. > > > > > > Ingo > > > > > >> If you mean milliseconds to bpm and vice versa: > > >> > > >> minute = 60,000 ms; > > >> > > >> bpm * ms = 60,000; > > >> > > >> bpm = 60,000 / ms; > > >> > > >> ms = 60,000 / bpm; > > >> > > >> [120 \ > > >> | > > >> [t b f] > > >> | / > > >> [6( > > >> | / > > >> [/ ] > > >> | > > >> [500 \ > > >> > > >> Send this to the right inlet of [metro]. Then connect a counter > > >> [int ]/[+ 1]/[% 16] (outlet of the modulo to right inlet of [int]) > > >> to the outlet of [metro]. That then counts from 0 to 15 with an > > >> interval of 500 ms. > > >> > > >> --Funs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] "musical" timing, something like Max´s "metrical timing Transport" and [metro 16n]
I don't have an exact plan on how to do this without spending a lot of time finding the most effective way for getting the accurate sample positions. Maybe someone else has done that before. However, in your particular case I would simply use midi clock from Ableton to sync the two. That looks much easier. If your timing resolution is a maximum of 24 clocks per quarter note you don't have to do anything. Just trigger the Pd sequencer steps from the incoming midi clock. If you need a higer resolution you could simply use a [timer], [cputime] or [realtime] to check the time from one clock to another and use that for subdividing for higher resolutions. As in the example below with 120 BPM and 500 ms per beat each midi clock would have a resolution of 20.8... ms (500 / 24). Using a resolution of 96 / quarter note you would have to divide this by 4 which comes out to 5.208333... ms. (BTW, you can see already from the 5.208333... ms that the time you would have to enter for the metro would render a tempo that is slightly off!) Syncing to midi clock would allow you to follow the tempo that is programmed in Ableton without having to worry about calculating the duration of each clock. In Pd use [midiin] and [route] or [select] to get F8 (hex) = 248 (decimal). This is how to get the clock time of 96 clocks / quarter note: [midiin] | [sel 248] | [t b b] | | [timer] | [/ 4] Don't start interpolation until the second incoming clock (or provide a usable value before the first clock is coming in). I.e. when starting jump from 0 to 4 and then increase by 1. Check out the midi specs for additional features like song pointer or midi timecode (which has nothing to do with midi clock), etc. Ingo > Thanks Ingo, I must do the testing. In fact Im recordind de midiout to > Ableton Live. > "recalculating the position from time to time and resyncing to the > absolute sample position might be necessary" how can I do this? > did you see my patch? im working with something lika a "master" metro > and a couple of "slave" metro objetcs that control a particular > sequence. > > > 2013/3/21 Ingo : > > I would assume that the rounding errors of metro would make the > > tempo > drift > > after a while - depending on the speed. > > > > Using the sample rate would be more accurate. > > > > In order to insure that the rounding errors are not influencing the > > the position after a long time recalculating the position from time > > to time > and > > resyncing to the absolute sample position might be necessary. > > > > However, such an accuracy would only be needed if the music is to be > synced > > to anything external like a DAW, I guess. > > > > Ingo > > > >> If you mean milliseconds to bpm and vice versa: > >> > >> minute = 60,000 ms; > >> > >> bpm * ms = 60,000; > >> > >> bpm = 60,000 / ms; > >> > >> ms = 60,000 / bpm; > >> > >> [120 \ > >> | > >> [t b f] > >> | / > >> [6( > >> | / > >> [/ ] > >> | > >> [500 \ > >> > >> Send this to the right inlet of [metro]. Then connect a counter > >> [int ]/[+ 1]/[% 16] (outlet of the modulo to right inlet of [int]) > >> to the outlet of [metro]. That then counts from 0 to 15 with an > >> interval of 500 ms. > >> > >> --Funs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] "musical" timing, something like Max´s "metrical timing Transport" and [metro 16n]
I would assume that the rounding errors of metro would make the tempo drift after a while - depending on the speed. Using the sample rate would be more accurate. In order to insure that the rounding errors are not influencing the the position after a long time recalculating the position from time to time and resyncing to the absolute sample position might be necessary. However, such an accuracy would only be needed if the music is to be synced to anything external like a DAW, I guess. Ingo > If you mean milliseconds to bpm and vice versa: > > minute = 60,000 ms; > > bpm * ms = 60,000; > > bpm = 60,000 / ms; > > ms = 60,000 / bpm; > > [120 \ > | > [t b f] > | / > [6( > | / > [/ ] > | > [500 \ > > Send this to the right inlet of [metro]. Then connect a counter [int > ]/[+ 1]/[% 16] (outlet of the modulo to right inlet of [int]) to the > outlet of [metro]. That then counts from 0 to 15 with an interval of > 500 ms. > > --Funs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help to load sound
There is a size limit for the file. I'm not sure whether this is 400 or anything else. Sombody else here might know. Ingo > Thank for your answer, I will trying to modificate my own error but now > the error message say: > > error: soundfiler_read: truncated to 400 elements > ... you might be able to track this down from the Find menu. > > when I load sound with [soundfiler] and [tabread~ sound]. > > I hope that my message is enough clear to permit you to understand what's > wrong > > Thanks to take the time to help me. > > Romain >> Message du 13/01/13 12:47 >> De : "Ingo" >> A : "'romain.darracq'" , pd-list@iem.at >> Copie à : >> Objet : AW: [PD] Help to load sound >> >> Try to use a name and path without spaces. >> Try the most simple path first like e.g. "C:\\Shake.mp3". >> >> Out of the objects that you named only [mp3play~] can play back MP3s. >>Make sure it is a "MP3 layer III" - otherwise it won't work. >> You could convert it to WAV for the others to be able to read it. >> >> Ingo > > > > Hello everybody, > I'm starting pd, and i have always the same matter when I want to load a > sound, pd say me: (error: dsp: C:/Documents and > Settings/Romain/Bureau/matrice perso/SON/musikkk/Remko Scha - (1982) Machine > Guitars/01 Shake.mp3: unknown or bad header format) and for all format > althrough i used [readsf~] or [mp3play~] or [soundfiler] objects > I have an other error's message :(error: endianness neither 'b' nor 'l' > ... you might be able to track this down from the Find menu.) ? > If someone can help me ?? > > Thanks > > Romain > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help to load sound
Try to use a name and path without spaces. Try the most simple path first like e.g. "C:\\Shake.mp3". Out of the objects that you named only [mp3play~] can play back MP3s. Make sure it is a "MP3 layer III" - otherwise it won't work. You could convert it to WAV for the others to be able to read it. Ingo Hello everybody, I'm starting pd, and i have always the same matter when I want to load a sound, pd say me: (error: dsp: C:/Documents and Settings/Romain/Bureau/matrice perso/SON/musikkk/Remko Scha - (1982) Machine Guitars/01 Shake.mp3: unknown or bad header format) and for all format althrough i used [readsf~] or [mp3play~] or [soundfiler] objects I have an other error's message :(error: endianness neither 'b' nor 'l' ... you might be able to track this down from the Find menu.) ? If someone can help me ?? Thanks Romain ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Increment/Decrement a number
Here's a counter that lets you count the same value from separate locations like counter buttons, incremental wheels, ext. midi input, etc. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Sebastian Valenzuela Gesendet: Donnerstag, 6. Dezember 2012 05:56 An: Pure Data Forum Betreff: [PD] Increment/Decrement a number Hi, Can anyone help me figure out how to increase a number by 1 by pressing a button, then decrease it by 1 by pressing a different button? I've attached my attempt, but it is acting strange :/ Thank you, Sebastian #N canvas 1074 156 643 366 10; #X obj 35 44 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 119 172 5 0 0 0 - - -; #X obj 119 141 \$1; #X obj 19 201 + 1; #X obj 179 234 spigot; #X obj 179 201 - 1; #X obj 190 44 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 218 141 0; #X msg 258 141 1; #X obj 19 234 spigot; #X msg 18 141 0; #X msg 58 141 1; #X msg 134 28 0; #X obj 35 67 t b b b; #X obj 190 67 t b b b; #X floatatom 102 276 5 0 0 0 - - -; #X text 130 12 reset; #X obj 365 6 table counter; #X obj 358 27 cnv 15 230 160 empty empty empty 20 12 0 14 -262130 -66577 0; #X obj 358 197 cnv 15 230 160 empty empty empty 20 12 0 14 -261682 -66577 0; #X msg 365 56 0; #X msg 485 56 0; #X floatatom 365 164 5 0 0 0 - - -; #X text 362 39 minus; #X text 482 39 plus; #X obj 365 76 tabread counter; #X obj 485 76 tabread counter; #X obj 485 96 + 1; #X obj 365 96 - 1; #X msg 485 136 \$1 0; #X obj 485 163 tabwrite counter; #X msg 535 136 0 0; #X text 530 119 reset; #X text 402 26 counter access 1; #X msg 365 226 0; #X msg 485 226 0; #X floatatom 365 334 5 0 0 0 - - -; #X text 362 209 minus; #X text 482 209 plus; #X obj 365 246 tabread counter; #X obj 485 246 tabread counter; #X obj 485 266 + 1; #X obj 365 266 - 1; #X msg 485 306 \$1 0; #X obj 485 333 tabwrite counter; #X msg 535 306 0 0; #X text 530 289 reset; #X text 402 196 counter access 2; #X connect 0 0 13 0; #X connect 2 0 3 0; #X connect 2 0 1 0; #X connect 2 0 5 0; #X connect 3 0 9 0; #X connect 4 0 2 1; #X connect 4 0 15 0; #X connect 5 0 4 0; #X connect 6 0 14 0; #X connect 7 0 4 1; #X connect 8 0 4 1; #X connect 9 0 2 1; #X connect 9 0 15 0; #X connect 10 0 9 1; #X connect 11 0 9 1; #X connect 12 0 2 1; #X connect 13 0 2 0; #X connect 13 1 11 0; #X connect 13 2 7 0; #X connect 14 0 2 0; #X connect 14 1 8 0; #X connect 14 2 10 0; #X connect 20 0 25 0; #X connect 21 0 26 0; #X connect 25 0 28 0; #X connect 26 0 27 0; #X connect 27 0 22 0; #X connect 27 0 29 0; #X connect 28 0 22 0; #X connect 28 0 29 0; #X connect 29 0 30 0; #X connect 31 0 30 0; #X connect 34 0 39 0; #X connect 35 0 40 0; #X connect 39 0 42 0; #X connect 40 0 41 0; #X connect 41 0 36 0; #X connect 41 0 43 0; #X connect 42 0 36 0; #X connect 42 0 43 0; #X connect 43 0 44 0; #X connect 45 0 44 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Increment/Decrement a number
This is how I would fix your current patch. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Sebastian Valenzuela Gesendet: Donnerstag, 6. Dezember 2012 05:56 An: Pure Data Forum Betreff: [PD] Increment/Decrement a number Hi, Can anyone help me figure out how to increase a number by 1 by pressing a button, then decrease it by 1 by pressing a different button? I've attached my attempt, but it is acting strange :/ Thank you, Sebastian #N canvas 1304 156 450 300 10; #X obj 115 44 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 199 172 5 0 0 0 - - -; #X obj 199 141 \$1; #X obj 99 201 + 1; #X obj 259 234 spigot; #X obj 259 201 - 1; #X obj 270 44 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 298 141 0; #X msg 338 141 1; #X obj 99 234 spigot; #X msg 98 141 0; #X msg 138 141 1; #X msg 214 28 0; #X obj 115 67 t b b b; #X obj 270 67 t b b b; #X floatatom 182 276 5 0 0 0 - - -; #X text 210 12 reset; #X connect 0 0 13 0; #X connect 2 0 3 0; #X connect 2 0 1 0; #X connect 2 0 5 0; #X connect 3 0 9 0; #X connect 4 0 2 1; #X connect 4 0 15 0; #X connect 5 0 4 0; #X connect 6 0 14 0; #X connect 7 0 4 1; #X connect 8 0 4 1; #X connect 9 0 2 1; #X connect 9 0 15 0; #X connect 10 0 9 1; #X connect 11 0 9 1; #X connect 12 0 2 1; #X connect 13 0 2 0; #X connect 13 1 11 0; #X connect 13 2 7 0; #X connect 14 0 2 0; #X connect 14 1 8 0; #X connect 14 2 10 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] osc processing array to the pd table
The first number is the value and the second number is the position. Ingo > The 1st arg of the list is the position where to write in the table. > you certainly want to add a 0 in front of the list. > cheers > c > > > Le 30/09/2012 04:11, Billy Stiltner a écrit : > > got another question > > > > > > > > [2 5.5 7 9 3( > > | > > [s mytable] > > > > > > [table mytable] > > > > > > why do I not get a write to mytable[0] with a 2 when i click the > messagebox? > > > > ___ > > 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] loading sounds stops my audio
Soundfiler interrupts the audiostream. This has been discussed here before. Ingo Betreff: Re: [PD] loading sounds stops my audio Try to put the table in a subpatch. It should work this way. On Thu, Sep 27, 2012 at 1:38 PM, xiaoping lyu wrote: Hi, in pd loading a sound into a table while pd is making sounds makes stops the audio for a few seconds. Is there a specific way of trick for avoiding this? any idea would be appreciated. cheers Xiao. ___ 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] Close PD window with a message?
Does anybody know if this works with 0.42.5 or does it need 0.43? Thanx Ingo > http://puredata.info/downloads/kiosk-plugin > > > > does anyone no if I can close the PD window (console) with a message > > within > > my patch in PD-extended-0.43. I only want to see the patch (parent) > > window > > at startup. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] interpolating between 2 streams
Maybe [average]? > Hi list, one question: i have 2 abstractions that are generating > streams of data, ,how can i interpolate between this 2 streams? for > example when my slider is the left then the output is stream "a" and > when my slider moves to the right it gradually convert into stream "b" > . Is there is an easy way for doing this? > > thanks > > R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] That old -nogui/nosound problem on Linux ...
I have had a similar problem when upgrading from Hardy to Lucid / Natty. In my case it was [susloop] that didn't work anymore with the -nogui flag. I wrote an abstraction to do the same thing and my patch was working again. It looks like some objects need updates to work with a newer OS and -nogui. Ingo > On Apr 10, 2012, at 11:11 AM, Chrissie Caulfield wrote: > > > Hi all, > > > > I've been scouring the lists for a solution to this but none of them > seem to work for me. Almost all non-trivial patches produce no sound with > the -nogui flag, even with the delayed startup or the workaround_loader.pd > that was posted here some time ago. > > > > > I know very little about the pd code but I'm a competent C professional > programmer and really want to fix this. Does anyone have any ideas where I > might start to look or is it still 'voodoo'? ;-) > > > > I'm using pd-extended from git & externals from svn, checked out this > morning. > > > > I've managed to make this trivial patch that reproduces the problem (and > includes the startup delay). I don't know why polygate~ does show the > problem where hip~ and friends don't but I'm hoping it's a clue! > > > > So, does anyone have any (even vague) ideas of where to start before I > start randomly digging? > > > > Chrissie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_film and readsf not in sync....
Could it be possible that your soundfile is being played back with the wrong samplerate? Like 48k instead of 44.1k? Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > altern > Gesendet: Donnerstag, 8. März 2012 14:59 > An: pd-list > Betreff: [PD] pix_film and readsf not in sync > > hi > > I am reading a video with pix_film and trigger it using auto, at the > same time load a sound file with readsf ~ . This is ok for a while but > after some time they go out of sync. The sound goes faster than the > video. > > Any simple solution to this? or do I need to construct my own system > to play the video passing the frame number to the pix_film? maybe > using a line object with the total num of frames and the total time > length of the video ... > > thanks > > enrike ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] WG: no tilde
I have to press "~" twice before it gets accepted on Ubuntu. Only once with Windows, though. Ingo > > -Ursprüngliche Nachricht- > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > Gerhard Lang > > Gesendet: Sonntag, 4. März 2012 18:03 > > An: pd-list@iem.at > > Betreff: [PD] no tilde > > > > and here is my first request for guiding hands: > > pd-extended 0.42.5 does not take the ~. > > I can copy the tilde from a text file and paste into objects with > > middlemouseclick. > > There is no keyboard dysfunction otherwise on my tp410 with ubuntu 11.4 > > amd64. > > Thanks in advance > > Gerhard ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI input problems in PD
I was using MIDI OX as well. I wonder if Laura did. If yes, it could be related to MIDI OX as well. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Miller Puckette > Gesendet: Sonntag, 26. Februar 2012 22:11 > An: Pierre-Olivier Boulant > Cc: PD-List > Betreff: Re: [PD] MIDI input problems in PD > > Drat, I can't reproduce this yet... I don't have any real MIDI devices, > just USB keyboards that fake MIDI, so perhaps I need to track down an > old-fashioned MIDI device somewhere :) > > M > > On Sun, Feb 26, 2012 at 08:15:32PM +0100, Pierre-Olivier Boulant wrote: > > Hi, > > > > I have the same problem. It affects several computers running XP, > > Vista or Win7 and several Midi controllers; either connected to a > > RME multiface or through USB (Korg NanoPad / Berinhger BCR2000 or > > BCF2000 / Akai LPD8). Mostly using CC, hardly Midi-notes. And most > > of the time I go through Midi-Ox and a virtual midi port (midi yoke) > > to merge all controllers before sending to Pd. Midi-Ox checks for > > looping and should be able to prevent it and my patches try to limit > > looping and Midi data flow too. > > > > It does look like there is some overflow of the midi I/O buffers. > > > > I tend to limit the flow of data outgoing with [speedlim] and have a > > separate sessions of Pd for the control/GUI and audio with the > > audio/midi properties set differently between the two sessions. > > > > For me it happens after big rushes of data: if I instantiate all the > > parameters of a BCR2000 at once (over 100 parameters) at the same > > time as updating the GUI in Pd it's not that hard to overload the > > midi buffers and create this problem and it doesn't take two hours > > to crash then... :) > > And if you send a lot of stuff from the controllers too then it can > > lead to the same issue. > > I'm not sure it's only the flow of midi data, but it could be the > > Midi data plus a lot of processing in Pd, especially with GUI > > objects moving in response to the Midi input. > > > > Re-instantiating the Midi-settings seems to flush the buffers, but > > sometimes it takes a reboot to make the problem go away once > > everything is stuck. > > > > Cheers > > Pierre-Olivier > > > > > > > > > > On 26/02/2012 08:28, Ingo wrote: > > >I had the same problem with Windows XP and a RME Hammerfall DSP card > using > > >only the normal [notein], [ctlin], [toutchin] and [pgmin] for a > sampling > > >synth. I don't think it's the midi interface. RME has some of the best > > >drivers - very stable. > > > > > >Sometimes after a certain amount of time it started playing notes by > itself > > >and didn't seem to stop anymore. It sounded like notes or melodies that > I > > >had been playing before. Nothing random. > > > > > >Could it be possible that midi data is written into a buffer that does > not > > >get emptied anymore? Then something might trigger reading out that > buffer? > > > > > >I couldn't recreate why it happened. Most of the time it didn't do it > but > > >every once in a while it did. > > > > > >I had no problem ever running Nuendo for days on that same machine > > >programming midi. The same Pd patch was doing fine on a Linux computer > after > > >switching to Linux. > > > > > >Ingo > > > > > > > > > > > >>-Ursprüngliche Nachricht- > > >>Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > >>Miller Puckette > > >>Gesendet: Sonntag, 26. Februar 2012 00:04 > > >>An: Villa Anna > > >>Cc: pd-list > > >>Betreff: Re: [PD] MIDI input problems in PD > > >> > > >>I haven't seen this problem, but I have to admit I don't think I ever > > >>ran MIDI into a Windows machine for more than 2 hours at a time (back > > >>when I acually used MIDI Windows itself wasn't stable enough to run > for > > >>that long at a time :) > > >> > > >>It's hard to know whether this is the MOTU driver misbehaving in > windows 7 > > >>or something with Pd itself - my only suggestion would be to try > either > > >>(1) switching interfaces to something more modern than 828MKII or (2) > > >>try using some other software to see if the problem is specific to PD
Re: [PD] MIDI input problems in PD
I had the same problem with Windows XP and a RME Hammerfall DSP card using only the normal [notein], [ctlin], [toutchin] and [pgmin] for a sampling synth. I don't think it's the midi interface. RME has some of the best drivers - very stable. Sometimes after a certain amount of time it started playing notes by itself and didn't seem to stop anymore. It sounded like notes or melodies that I had been playing before. Nothing random. Could it be possible that midi data is written into a buffer that does not get emptied anymore? Then something might trigger reading out that buffer? I couldn't recreate why it happened. Most of the time it didn't do it but every once in a while it did. I had no problem ever running Nuendo for days on that same machine programming midi. The same Pd patch was doing fine on a Linux computer after switching to Linux. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Miller Puckette > Gesendet: Sonntag, 26. Februar 2012 00:04 > An: Villa Anna > Cc: pd-list > Betreff: Re: [PD] MIDI input problems in PD > > I haven't seen this problem, but I have to admit I don't think I ever > ran MIDI into a Windows machine for more than 2 hours at a time (back > when I acually used MIDI Windows itself wasn't stable enough to run for > that long at a time :) > > It's hard to know whether this is the MOTU driver misbehaving in windows 7 > or somethig with Pd itself - my only suggestion would be to try either > (1) switching interfaces to something more modern than 828MKII or (2) > try using some other software to see if the problem is specific to PD. > > cheers > Miller > > On Sat, Feb 25, 2012 at 11:03:32AM +0100, Villa Anna wrote: > > Dear list, > > > > I have problems with Midi input in PD. > > I use Windows 7 and make use of a Motu 828MKII soundcard. > > I receive MIDI via a polytouchin object (make use of FSRs and a coridium > > armmite to translate pressure on the FSRs to Midi messages). > > All goes fine in the beginning, but sometimes after a while (f.e. 2 > hours) > > my Midi input starts to be random (FSRs trigger that are not supposed to > be > > triggering). If I restart PD everything is back to normal. Any idea what > > the cause of this problem might be? > > It's an installation project so it is difficult to restart everything > from > > time to time. > > > > Thanks in advance for your help! > > > > Laura > > > ___ > > 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] (no subject)
I had the same problem with Windows XP. Even with the regular MIDI In objects like [notein] or [ctlin], etc. I gave up and switched to Linux. Ingo > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > Villa Anna > Gesendet: Samstag, 25. Februar 2012 11:04 > An: pd-list > Betreff: [PD] MIDI input problems in PD > > Dear list, > > I have problems with Midi input in PD. > I use Windows 7 and make use of a Motu 828MKII soundcard. > I receive MIDI via a polytouchin object (make use of FSRs and a > coridium armmite to translate pressure on the FSRs to Midi messages). > All goes fine in the beginning, but sometimes after a while (f.e. 2 > hours) > my Midi input starts to be random (FSRs trigger that are not > supposed to be triggering). If I restart PD everything is back to normal. Any idea what the cause of this problem might be? > It's an installation project so it is difficult to restart everything > from time to time. > > Thanks in advance for your help! > > Laura ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Audio line circuit breaker?
You'll have the choice whether to use the audio signal or the float. If the audio signal is connected it will override the float on the next sample. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Jonathan Wilkes > Gesendet: Dienstag, 15. November 2011 20:06 > An: tim vets > Cc: Pure Data Forum; i go bananas > Betreff: Re: [PD] Audio line circuit breaker? > > Seems like that would work, with "work" meaning it fulfills hc's request. > > But I don't understand hc's request-- you can already sent a float to an > audio > > inlet. What is the problem that's being addressedhere? > > > -Jonathan > > > > > >From: tim vets > >To: Jonathan Wilkes > >Cc: Hans-Christoph Steiner ; i go bananas > ; Pure Data Forum > >Sent: Tuesday, November 15, 2011 1:56 PM > >Subject: Re: [PD] Audio line circuit breaker? > > > > > >[inlet~] [inlet] > >| || [switch~] > >| > >[outlet~] > >? > > > > > > > > > >2011/11/15 Jonathan Wilkes > > > >see [sig~] > >> > >> > >> > >> > >>> > >>>From: Hans-Christoph Steiner > >>>To: i go bananas > >>>Cc: Pure Data Forum > >>>Sent: Tuesday, November 15, 2011 11:52 AM > >>>Subject: Re: [PD] Audio line circuit breaker? > >> > >>> > >>> > >>> > >>> > >>>That still sends the audio signal, tho its all 0s, I wonder if there is > an object that actually stops the flow of audio, i.e. behaves like an > unattached inlet. This is useful if you want to send a float message to > an audio inlet. > >>> > >>> > >>>.hc > >>> > >>>On Nov 15, 2011, at 2:18 AM, i go bananas wrote: > >>> > >>>[*~ ] > >>>> > >>>>(send a 1 or 0 to the right inlet to turn on and off) > >>>> > >>>>(do this after the 0 / 1 to avoid clicks: > >>>> > >>>> [$1 5( > >>>> | > >>>> [line~] > >>>> | > >>>>[*~ ] > >>>> > >>>> > >>>> > >>>> > >>>>On Tue, Nov 15, 2011 at 2:14 PM, Sebastian Valenzuela > wrote: > >>>> > >>>>Hi again, > >>>>> > >>>>>Can such a thing be built? Something you can put in between an audio > source and audio receiver (like an osc~ object going to a dac~) that would > either break that signal or allow audio to flow from one to the other > (On/Off). There is probably a very easy answer to this. > >>>>> > >>>>> > >>>>>Thank you for reading, > >>>>>Sebastian > >>>>>___ > >>>>>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 > >>>> > >>> > >>> > >>> > >>> > >>>--- > - > >>> > >>> > >>>"[W]e have invented the technology to eliminate scarcity, but we are > deliberately throwing it away to benefit those who profit from scarcity." > -John Gilmore > >>> > >>> > >>>___ > >>>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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
> Also, make sure that the Realtek chip does native 44.1... > I feed my MOTU card from the SPDIF output of a Creative Audigy* and I had > to change my workflow to 48k because the Audigy turned out to "fake" 44.1 > by constant upsampling/downsampling around its fixed-48k DSP. > > * because the FireWire connection is so fragile and the damn MOTU freezes > all the time > > Andras I used to have lots of sample rate problems with one of the older EMU cards because of that sound chip (back with Windows 98). It's a known problem with the Creative cards which is why I'm staying away from them. They are set to a fixed rate of 48k. The Realtek actually supports all standard rates up to 192k. Which means it simply can't be fixed like the Creative cards. Anyway, after finding the "PCM Default Playback Switch" and turning it on so it follows the software's sample rate it works fine. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
I think if you are using a mixed patch with osc and samples only the samples would play correctly and any osc~ might get detuned. Not sure? But anyway, as far as I know you can only up or downsample by the power of two. I did try to use a frequency multiplier of 0.91875 and it was playing in tune but that still gave me a samplerate of 48k at the SPDIF out instead of the 44.1k which was what I wanted. Anyway, I suspect that some instabilities as well as certain losses of sound quality may happen if the sample rate of Pd conflicts with the sample rate of the sound card. This is because of the resampling that the sound card needs to do. So getting Pd's sample rate matched up with the rate of the hardware might have advantages even if you are using only analogue outs. Ingo 2011/11/10 Roman Haefeli On Thu, 2011-11-10 at 17:14 +0100, tim vets wrote: > .. > Lastly: I wonder if there isn't a way to downsample some subpatches to > playback the 44.1kHz soundfiles in a 48kHz environment? Why would you want to run an [osc~ 440] at a different samplerate, when it plays a 440Hz anyway? Regarding audio samples, you can use [tabread4~] fed by a [line~] instead of [tabplay~] for up- or downsampling. it was just a thought, I can imagine if you would have based some sophisticated sample playback on a whole bunch of tabplay~'s or readsf~'s, that maybe you wouldn't want or have time to change all that... I checked [switch~] again and indeed you can enter 0.5 to downsample by factor 2, does that mean you could enter 0.918750007 to downsample from 48 to 44.1? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS) - Problem solved!
Problem solved! There is a switch at the soundcard mixer (I'm using "gamix") that is labeled "PCM Default Playback Switch". - If "OFF" it will set the soundcard to 48k - always (OSS default). - When set to "ON" it will follow the software's sample rate. So, recalling a mixer preset with this switch set to "ON" and changing the desired sample rate via Pd's audio dialog afterwards does the trick. Since the sample rate is output at start up of Pd the audio dialog needs to be set once more after recalling the mixer preset or the audio mixer preset needs to be loaded before Pd starts. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Ingo > Gesendet: Donnerstag, 10. November 2011 17:34 > An: 'IOhannes m zmoelnig'; pd-list@iem.at > Betreff: Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS) > > > > On 2011-11-10 13:10, Ingo wrote: > > > Hi everybody, > > > > > > I need some help about sample rate settings. > > > > > > I would like to use my SPDIF Out with Pd. Unfortunately it looks like > > either > > > the soundcard or the audio system (OSS) starts up with 48,000 Hz while > > Pd is > > > set to use 44,100 Hz (that's necessary because of the samples being at > > > 44.1k). > > > > i was going to say: you can change the samplerate of Pd to 48kHz using > > the Media->Audio menu. it will magically shorten each sample from > > (1/44.1)ms to (1/48)ms, so you don't need to worry about that. > > > > but then, maybe you meant your soundfiles? > > > > fgamsdr > > IOhannes > > Yep, I was talking about the soundfiles. It's a sample player synth. > Changing the samplerate of Pd will detune all instruments. > > The funny thing is that my older mainboard simply accepted the sample rate > from Pd. The new one doesn't. So it looks like it needs to be set up > before > Pd gets started. This has to be stored within a file somewhere. > I've read somewhere that OSS defaults to 48k. So it might actually be the > absence of a configuration file which makes it a bit more difficult to > find. > > Analogue outs work normally. Although I suspect there is resampling going > on > inside the soundcard. It's a realtek. They tend to do stuff like that. > > Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
It's not the HDSP that's causing the problems. It's a realtek onboard souncard. The HDSP was used on another (WinXP) computer and only served as an input to check the output of the linux machine. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von tim vets Gesendet: Donnerstag, 10. November 2011 17:15 An: IOhannes m zmoelnig Cc: pd-list@iem.at Betreff: Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS) Concerning your soundcard, you sould have HdspConf installed, no? There you can simply choose the samplerate with buttons. I don't have any experience with SPDIF, but I did recently started using an ADAT (optical) device with the HDSP/Hammerfall, for inputs. In my case, you have to set the ADAT device to 48 or 44.1 with a physical switch on the back, and have the soundcard sync to that. (also a setting in HdspConf) However, it seems like at 44.1kHz it's a lot less stable, it keeps losing sync and resyncing all the time, at least that's what the gui shows, but afaict it has no effect on the sound... Lastly: I wonder if there isn't a way to downsample some subpatches to playback the 44.1kHz soundfiles in a 48kHz environment? gr, Tim 2011/11/10 IOhannes m zmoelnig -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-10 13:10, Ingo wrote: > Hi everybody, > > I need some help about sample rate settings. > > I would like to use my SPDIF Out with Pd. Unfortunately it looks like either > the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is > set to use 44,100 Hz (that's necessary because of the samples being at > 44.1k). i was going to say: you can change the samplerate of Pd to 48kHz using the Media->Audio menu. it will magically shorten each sample from (1/44.1)ms to (1/48)ms, so you don't need to worry about that. but then, maybe you meant your soundfiles? fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk677vgACgkQkX2Xpv6ydvTm8wCdEhwpG+04NEttfTb2+SPN9Cmg MB0AoIUPlTey1lb5lJ5ji0f4o3fz74e6 =2RQo -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] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
> > On 2011-11-10 13:10, Ingo wrote: > > Hi everybody, > > > > I need some help about sample rate settings. > > > > I would like to use my SPDIF Out with Pd. Unfortunately it looks like > either > > the soundcard or the audio system (OSS) starts up with 48,000 Hz while > Pd is > > set to use 44,100 Hz (that's necessary because of the samples being at > > 44.1k). > > i was going to say: you can change the samplerate of Pd to 48kHz using > the Media->Audio menu. it will magically shorten each sample from > (1/44.1)ms to (1/48)ms, so you don't need to worry about that. > > but then, maybe you meant your soundfiles? > > fgamsdr > IOhannes Yep, I was talking about the soundfiles. It's a sample player synth. Changing the samplerate of Pd will detune all instruments. The funny thing is that my older mainboard simply accepted the sample rate from Pd. The new one doesn't. So it looks like it needs to be set up before Pd gets started. This has to be stored within a file somewhere. I've read somewhere that OSS defaults to 48k. So it might actually be the absence of a configuration file which makes it a bit more difficult to find. Analogue outs work normally. Although I suspect there is resampling going on inside the soundcard. It's a realtek. They tend to do stuff like that. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
Thanks Roman, but no - the soundcard supports up to 192k sampling rate and I do get it to playback at 44.1k every once in a while. When I switch PCM on/off a couple of times all the sudden it starts working correctly. I can see it on my RME-HDSP. It shows 48k at startup with no sound and after switching it on an off and resetting the samplerate in Pd a number of times it picks up the correct sample rate. The HDSP shows 44.1k and there is sound. So it does support 44.1k. The question is: How do I set this samplerate at system startup in Natty? I just read about a way how to do it in OSS4 but I'm still using the older OSS ( OSS 3 ? ) because of the MIDI support. Ingo > Hi Ingo > > On Thu, 2011-11-10 at 13:10 +0100, Ingo wrote: > > Hi everybody, > > > > I need some help about sample rate settings. > > > > I would like to use my SPDIF Out with Pd. Unfortunately it looks like > either > > the soundcard or the audio system (OSS) starts up with 48,000 Hz while > Pd is > > set to use 44,100 Hz (that's necessary because of the samples being at > > 44.1k). > > > > Does anybody know where or how I can set the PCM sample rate to match > Pd's > > sample rate? > > > > None of the soundcard mixers I was checking have an option to set the > sample > > rate and I don't know where the OSS files are located. > > I don't know about your soundcard, but many (cheap) soundcards only > support 48kHz. You probably won't notice it with ALSA, since ALSA is > capable of resampling the sound before pushing it to the card, but if > you really are using old-school OSS, I think there is no way to > resample. > > Just in case, you're sound card really only supports 48kHz, would > resampling your audio files be an option? At least then you have some > control over the resampling quality. > > Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
Hi everybody, I need some help about sample rate settings. I would like to use my SPDIF Out with Pd. Unfortunately it looks like either the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is set to use 44,100 Hz (that's necessary because of the samples being at 44.1k). Does anybody know where or how I can set the PCM sample rate to match Pd's sample rate? None of the soundcard mixers I was checking have an option to set the sample rate and I don't know where the OSS files are located. Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] clear console command + create folder from Pd?
> -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > João Pais > Gesendet: Dienstag, 8. November 2011 12:46 > An: Hans-Christoph Steiner > Cc: PD-List > Betreff: Re: [PD] clear console command + create folder from Pd? > > >> - is there any object that allows to create a folder (in all OSs)? I > >> wanted to save files to a non-existing folder, but Pd doesn't create > >> one. > > > > You could probably use Tcl's mkdir and send it to the GUI: > > > > [file mkidr /path/to/mynewfolder( > > | > > [hcs/sys_gui] > > this works, but only if I give a complete path, not a relative one. You could use [ggee/getdir] if you are on Pd-extended. I can > get the patche's current path with tof/path, but I read that tof isn't > included in the next versions? Is it possible to get the current path > through other methods? > > João Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] clear console command + create folder from Pd?
Thats working now, Tim. I did see already that the [loadbang] was missing. However, working with absolute directories gets really complicated this way. Especially if you want to have the same Patch or abstraction working on several platforms. I would suspect this version might only work on windows correctly? Ingo Von: tim vets [mailto:timv...@gmail.com] Gesendet: Dienstag, 8. November 2011 12:35 An: Ingo Cc: Hans-Christoph Steiner; pd list Betreff: Re: [PD] clear console command + create folder from Pd? 2011/11/8 tim vets 2011/11/8 Ingo >>> - is there any object that allows to create a folder (in all OSs)? >>> I wanted to save files to a non-existing folder, but Pd doesn't >>> create one. >> >> [mkdir $1(--[popen] ? > >I wonder if that works on Windows? Anyone tested it? Someone could >probably make [mkdir] object quite quickly using pdlua or tclpd. > >.hc I just tested it on WinXP. I could create a directory in the folder of the patch but not a subdirectory. Not sure if it has anything to do with the slash vs. backslash issue. Ah, true, I didn't think of that. I found a workaround though (see attachment), but it's getting absurdly complicated for just doing mkdir... and I forgot to add a loadbang, you have to click the [symbol( connected to [l2s] first... Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list #N canvas 1260 409 345 335 10; #X obj 240 289 popen; #X obj 95 93 makefilename %c; #X obj 67 223 l2s; #X obj 67 161 pack s s s; #X msg 136 206 symbol; #X obj 67 252 prepend mkdir; #X obj 67 289 print; #X msg 95 72 92; #X msg 124 140 symbol testdd; #X msg 67 113 symbol testd; #X obj 67 52 t b b b; #X msg 240 64 mkdir testd; #X obj 67 32 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 89 5 1 make directory 'testd' in current; #X obj 67 6 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 86 28 2 make subdirectory 'testdd' in 'testd'; #X obj 136 186 loadbang; #X connect 1 0 3 1; #X connect 2 0 5 0; #X connect 3 0 2 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 5 0 0 0; #X connect 7 0 1 0; #X connect 8 0 3 2; #X connect 9 0 3 0; #X connect 10 0 9 0; #X connect 10 1 7 0; #X connect 10 2 8 0; #X connect 11 0 0 0; #X connect 12 0 10 0; #X connect 14 0 11 0; #X connect 16 0 4 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] clear console command + create folder from Pd?
>>> - is there any object that allows to create a folder (in all OSs)? >>> I wanted to save files to a non-existing folder, but Pd doesn't >>> create one. >> >> [mkdir $1(--[popen] ? > >I wonder if that works on Windows? Anyone tested it? Someone could >probably make [mkdir] object quite quickly using pdlua or tclpd. > >.hc I just tested it on WinXP. I could create a directory in the folder of the patch but not a subdirectory. Not sure if it has anything to do with the slash vs. backslash issue. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Interruption of audio / Loading sound into array
> This might just be a graphics related problem. It's not! Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von David Schaffer Gesendet: Donnerstag, 3. November 2011 12:31 An: pd list Betreff: Re: [PD] Interruption of audio / Loading sound into array Hi, This might just be a graphics related problem. Just disable the graphical representation of the arrays (I'm not in front of Pd right now but If I remeber well, it's just a matter of clicking on the arrays and unchecking the "graph on parent" box). I had the very same problem under Win XP, it solved everything. Hope this helps. D.S http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/ > From: i...@miamiwave.com > To: sebastian.han...@gmx.de; pd-list@iem.at > Date: Mon, 31 Oct 2011 19:24:20 +0100 > Subject: Re: [PD] Interruption of audio / Loading sound into array > > [soundfiler] will always interrupt the audio stream. > > What I have done before was to stream the soundfile into a table with > [readsf~]. You can upsample the subpatch with [block~] or [switch~] so it > reads faster than realtime. > > Ingo > > > > > -Ursprüngliche Nachricht- > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > > Sebastian Hanusa > > Gesendet: Montag, 31. Oktober 2011 18:37 > > An: pd-list@iem.at > > Betreff: [PD] Interruption of audio / Loading sound into array > > > > Dear List! > > > > I have a problem, where hope the solution is so easy as it is > > complicated for me to find a solution: > > > > When I am loading a soundfile (about one 30 seconds, stereo, .aif, > > 16bit/44100Hz) to an array and simultaneously I have a quite simple > > audio prozess like replaying a second soundfile with [readsf] + for > > example a delay and a bandbass I get in the moment of loading to the > > array a dropout of the audio stream. > > > > I tryed to switch off the patch within the array for the moment of > > loading - but I get the same result. > > > > Is there a way to avoid this dropout? > > > > I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 > > Duo, OS X 10.5.8 > > > > Thanks a lot for any help and with best regards, > > > > Sebastian > > > > ___ > 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] Interruption of audio / Loading sound into array
[soundfiler] will always interrupt the audio stream. What I have done before was to stream the soundfile into a table with [readsf~]. You can upsample the subpatch with [block~] or [switch~] so it reads faster than realtime. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Sebastian Hanusa > Gesendet: Montag, 31. Oktober 2011 18:37 > An: pd-list@iem.at > Betreff: [PD] Interruption of audio / Loading sound into array > > Dear List! > > I have a problem, where hope the solution is so easy as it is > complicated for me to find a solution: > > When I am loading a soundfile (about one 30 seconds, stereo, .aif, > 16bit/44100Hz) to an array and simultaneously I have a quite simple > audio prozess like replaying a second soundfile with [readsf] + for > example a delay and a bandbass I get in the moment of loading to the > array a dropout of the audio stream. > > I tryed to switch off the patch within the array for the moment of > loading - but I get the same result. > > Is there a way to avoid this dropout? > > I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 > Duo, OS X 10.5.8 > > Thanks a lot for any help and with best regards, > > Sebastian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] bendin-bendout under Linux
> -Ursprüngliche Nachricht- > Von: Mathieu Bouchard [mailto:ma...@artengine.ca] > Gesendet: Dienstag, 4. Oktober 2011 17:06 > An: Hans-Christoph Steiner > Cc: Ingo; pd-list@iem.at > Betreff: Re: [PD] bendin-bendout under Linux > > Le 2011-10-04 à 10:53:00, Hans-Christoph Steiner a écrit : > > On Oct 4, 2011, at 10:41 AM, Mathieu Bouchard wrote: > >> Le 2011-10-04 à 11:50:00, Ingo a écrit : > >> > >>> I can't really see how 0.42.5 could use or output a different > pitchbend > >>> range than 0.43. If this was the case all patches using pitchbend > would be > >>> broken on 0.43 if they were made with an earlier version. I would call > >>> that a major disaster. > >> > >> I've been using pd-extended 42 for nearly two years now, and all what I > >> tried with pitchbend was with that, and it worked. > > > > Try with vanilla 0.43 and see if it works there. Please file a bug > report. > > I don't have problems with pitchbend. > > __ > | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC Neither do I! I just don't believe that it works differently on 0.43 (which I don't have installed unfortunately) compared to 0.42.5. 0.42.5 works as expected! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] bendin-bendout under Linux
I can't really see how 0.42.5 could use or output a different pitchbend range than 0.43. If this was the case all patches using pitchbend would be broken on 0.43 if they were made with an earlier version. I would call that a major disaster. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Nicola Pandini > Gesendet: Dienstag, 4. Oktober 2011 10:46 > An: pd-list@iem.at > Betreff: Re: [PD] bendin-bendout under Linux > > Il 04/10/2011 06:21, Ingo ha scritto: > > > >> -Ursprüngliche Nachricht- > >> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > >> Lorenzo Sutton > >> Gesendet: Montag, 3. Oktober 2011 22:25 > >> An: pd-list@iem.at > >> Betreff: Re: [PD] bendin-bendout under Linux > >> > >> On 03/10/2011 20:13, Nicola Pandini wrote: > >>> Il 03/10/2011 19:33, Mathieu Bouchard ha scritto: > >>>> Le 2011-10-03 à 19:29:00, Nicola Pandini a écrit : > >>>> > >>>>> Hi, I'm trying to build a patch that routes notes, CCs and pitch > bend > >>>>> from a keyboard to different synths. > >>>>> Everything is ok for notes and CCs, but I have a problem with the > >>>>> pitch bend. > >>>>> It seems that [bendout] can outputs only a range between 0 and > 16384, > >>>>> while the correct range should be -8192 +8192. > >>>>> I tried to force negative values but it seems that bendout can't go > >>>>> below 0. > >>>> use [- 8192] > >>>> > >>>> because 0-8192 = -8192 > >>>> and because 16383-8192 = 8191 > >>>> > >>>> that is, in unsigned values, 8192 is the middle of the range. > >>>> > >>> You right, but I already tried this: > >>> > >>> #N canvas 93 232 450 300 10; > >>> #X obj 82 77 bendin; > >>> #X obj 82 102 - 8192; > >>> #X obj 82 130 bendout 1; > >>> #X connect 0 0 1 0; > >>> #X connect 1 0 2 0; > >>> > >>> And bendout had only a range from 0 to 8192, it didn't go below 0. > >>> > >> Strange I tested (with rosegarden and gmidimonitor) on 0.43 and it > >> worked outputting the whole range -8191 to 8192. > >> Lorenzo > > > > This depends on how the software is "displaying" pitchbend. Pd always > uses 0 > > - 16383. MIDI does always transmit 7-bit values from 0 - 127 (except for > > SysEx). This is a 14-bit message cascaded by two 7-bit messages - each > going > > from 0 - 127. > > > > Generally the msb is being used and the lsb is left at 0 (maybe it's the > > other way around). This means the center value of Pitchbend is 64 0. > > You can eliminate the second byte by dividing by 128. > > > > For displaying the value is offset by 8192 by certain softwares to show > > negative values. Some people might think it looks more understandable to > > have the same range going negative or positive for bend down / bend up. > But > > the numbers still go from 0 - 16383. Center is 8192 or 64 0. > > > > Ingo > > > > > > ___ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > Thanks for all the feedbacks. > On Debian Wheezy I tried the following setup: > vkeybd -> Pd -> qmidiroute > > On 0.42.5, the numbers starts from 0 even with the [- 8192] object. > On 0.43, as Lorenzo said, I can get the correct range (-8192 8192), so > it seems to be only a 0.42.5 issue. > > -- > Nicola Pandini > http://www.cassandraweb.it > http://www.myspace.com/thewhitewhisper > http://www.myspace.com/cassandraweb > > > ___ > 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] bendin-bendout under Linux
> -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Lorenzo Sutton > Gesendet: Montag, 3. Oktober 2011 22:25 > An: pd-list@iem.at > Betreff: Re: [PD] bendin-bendout under Linux > > On 03/10/2011 20:13, Nicola Pandini wrote: > > Il 03/10/2011 19:33, Mathieu Bouchard ha scritto: > >> Le 2011-10-03 à 19:29:00, Nicola Pandini a écrit : > >> > >>> Hi, I'm trying to build a patch that routes notes, CCs and pitch bend > >>> from a keyboard to different synths. > >>> Everything is ok for notes and CCs, but I have a problem with the > >>> pitch bend. > >>> It seems that [bendout] can outputs only a range between 0 and 16384, > >>> while the correct range should be -8192 +8192. > >>> I tried to force negative values but it seems that bendout can't go > >>> below 0. > >> > >> use [- 8192] > >> > >> because 0-8192 = -8192 > >> and because 16383-8192 = 8191 > >> > >> that is, in unsigned values, 8192 is the middle of the range. > >> > > > > You right, but I already tried this: > > > > #N canvas 93 232 450 300 10; > > #X obj 82 77 bendin; > > #X obj 82 102 - 8192; > > #X obj 82 130 bendout 1; > > #X connect 0 0 1 0; > > #X connect 1 0 2 0; > > > > And bendout had only a range from 0 to 8192, it didn't go below 0. > > > > Strange I tested (with rosegarden and gmidimonitor) on 0.43 and it > worked outputting the whole range -8191 to 8192. > Lorenzo This depends on how the software is "displaying" pitchbend. Pd always uses 0 - 16383. MIDI does always transmit 7-bit values from 0 - 127 (except for SysEx). This is a 14-bit message cascaded by two 7-bit messages - each going from 0 - 127. Generally the msb is being used and the lsb is left at 0 (maybe it's the other way around). This means the center value of Pitchbend is 64 0. You can eliminate the second byte by dividing by 128. For displaying the value is offset by 8192 by certain softwares to show negative values. Some people might think it looks more understandable to have the same range going negative or positive for bend down / bend up. But the numbers still go from 0 - 16383. Center is 8192 or 64 0. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
Actually, I do have a twin brother. I could almost compete with the guy on the picture. Since I am using 3 stereo outs I could maybe top that with around something like six ears. I'll have to see how quickly I can clone myself! I'm not sure if Pd supports cloning of the listener with the current version? Maybe with an abstraction like: [dac~] | \ [ear~ $1] [ear~ $2] Then do some dynamic patching? Ingo > -Ursprüngliche Nachricht- > Von: Mathieu Bouchard [mailto:ma...@artengine.ca] > Gesendet: Montag, 3. Oktober 2011 19:38 > An: Ingo > Cc: 'Pd List' > Betreff: Re: AW: [PD] Fwd: Variable number of objects? > > Le 2011-10-01 à 04:14:00, Ingo a écrit : > > >> I wonder what kind of ears it takes to listen to something so > complex... > >> rather, what kind of brain lobes it takes. > > > > It takes a regular pair of ears - one on the left side and one on the > right > > side! > > per head ? > > how many heads do you have ? > > e.g. quadraphonic : > http://upload.wikimedia.org/wikipedia/en/7/72/Mark_Wing- > Davey_as_Zaphod_Beeblebrox.jpg > > __ > | 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
Re: [PD] Fwd: Variable number of objects?
Ok, it looks like I was misunderstanding the way how the [send] / [receive] is working. But then I am still wondering why I got a lot of performance boost after replacing the [send] / [receive] with wired connections? Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > IOhannes m zmölnig > Gesendet: Samstag, 1. Oktober 2011 18:18 > An: pd-list@iem.at > Betreff: Re: [PD] Fwd: Variable number of objects? > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/01/2011 04:48 AM, Ingo wrote: > > Every [receive] will have to check if any [send] message is meant to be > for > > this particular [receive]. It will have to check if the header of the > [send] > > matches the header of the [receive] until the first character doesn't > match > > anymore. Then it will abort checking and the next [receive] will start > > checking, and so on ... > > I can't see how this can be done without taxing the cpu. > > this is not how send/receive work in Pd. > in general, Pd's messaging system works in a "push" manner, where data > is pushed from one object to the next, rather than a "pull" manner, > where an object requests a message from the previous one. > > therefore, [receive] need not care which [send]s are attached to it. > > then, [send] need not search for attached [receive]s either, because the > send-symbol will maintain a linked list of all attached receivers. > going through the linked list for dispatching a message is quite fast. > > gfdstm > IOhannes > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6HPTEACgkQkX2Xpv6ydvQ8bQCfStNUi4fxyCOe2ZK3uvHtN7BG > p+oAoNqIIRG/oaeeD7Qjoi2mmgkNXcZV > =Chc9 > -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] Fwd: Variable number of objects?
> If you're going to wire them why not just create specific send messages? > > Give every abstraction an index and send only to that one: > > [r $1-foo] > | > etc > > J Every [receive] will have to check if any [send] message is meant to be for this particular [receive]. It will have to check if the header of the [send] matches the header of the [receive] until the first character doesn't match anymore. Then it will abort checking and the next [receive] will start checking, and so on ... I can't see how this can be done without taxing the cpu. Having several hundred of messages being sent per second going to several hundred [receives] multiplied by the voice number will add up to many millions of these checks per second. After a certain amount of objects and input data this definitely takes too much time for realtime low latency playing when using high voice counts. It may not affect anything until the number of [send/receive] exceeds a certain number. Getting rid of the [send/receive]s at this point takes a ridiculous amount of time (I'm still not done after several months but getting much better results already). Using dollar arguments only adds a number to the [receive] and doesn't keep it from having to do the checking. That's the reason why I try to avoid [send/receive] objects wherever realtime playing is involved. I still use them, but only for non realtime editing purposes. But there is still a tendency for audio dropouts. Ingo > On Sep 30, 2011, at 4:13 AM, "Ingo" wrote: > > > I actually do switch off everything possible with a spigot but the > > [receive]s do still need to check if the [send] message is meant to be > for > > them or not. So once you get too many [receive] objects while sending a > lot > > it CAN slow down the patch quite a bit. But unfortunately that only > starts > > showing up once the patch is so big that it takes forever to replace all > of > > the [receive] objects with wired connections. > > > > So for now I'm trying to use wires wherever possible to address data > only to > > the object that needs the data rather than having ten thousands of > objects > > checking hundreds of times per second if the data is meant to be for > them or > > not. > > > > Ingo > > > > > >> -Ursprüngliche Nachricht- > >> Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] > >> Gesendet: Freitag, 30. September 2011 05:04 > >> An: Ingo > >> Cc: Jonathan Wilkes; Pd List > >> Betreff: Re: [PD] Fwd: Variable number of objects? > >> > >> I see... > >> > >> What I do is put a spigot right after all receives and the spigot is > >> controlled by the same messages that control switch~: > >> > >> [r foo] > >> | > >> [spigot 0] > >> | > >> ... > >> > >> In this way you'll at least stop using all lines and metros and the > >> like. I am not entirely sure that having a receive immediately > >> connected to a [spigot 0] has any computational expense, but if I'm > >> measuring things correctly they don't. So no need to shut off > >> receives, just send them to a closed gate > >> > >> best, > >> > >> J > >> > >> On Thu, Sep 29, 2011 at 10:30 PM, Ingo wrote: > >>>> Why would you have control messages going if switch~ is off? > >>> > >>> Because the voice gets assigned to a certain midi channel when it > >> receives a > >>> [noteon] and has to keep receiving all midi controllers on that > channel > >>> until the envelope release has finished. Then the next voice will play > >> on > >>> that same midi channel. There is nothing that cuts off the control > >> inlets or > >>> [send/receive]s automatically because the audio gets switched off. > >>> So when you play 16 notes in a row all 16 voices are set up to receive > >>> control data on that particular midi channel. Everything in the > control > >>> domain, like LFOs, [metro]s and [line]s keep running and keep > >> calculating > >>> pitch, volume, filter offsets and so on ... > >>> > >>> Turning off the [receive]s would be very complicated if not impossible > >> which > >>> is why they need to be avoided wherever it can be done. But all of the > >> wired > >>> inlets can be cut off manually together with the [switch~] and turned > >> back > >>> on when the next note will play that voice. On top of it all 500 > >> par
Re: [PD] Fwd: Variable number of objects?
> I wonder what kind of ears it takes to listen to something so complex... > rather, what kind of brain lobes it takes. It takes a regular pair of ears - one on the left side and one on the right side! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
I actually do switch off everything possible with a spigot but the [receive]s do still need to check if the [send] message is meant to be for them or not. So once you get too many [receive] objects while sending a lot it CAN slow down the patch quite a bit. But unfortunately that only starts showing up once the patch is so big that it takes forever to replace all of the [receive] objects with wired connections. So for now I'm trying to use wires wherever possible to address data only to the object that needs the data rather than having ten thousands of objects checking hundreds of times per second if the data is meant to be for them or not. Ingo > -Ursprüngliche Nachricht- > Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] > Gesendet: Freitag, 30. September 2011 05:04 > An: Ingo > Cc: Jonathan Wilkes; Pd List > Betreff: Re: [PD] Fwd: Variable number of objects? > > I see... > > What I do is put a spigot right after all receives and the spigot is > controlled by the same messages that control switch~: > > [r foo] > | > [spigot 0] > | > ... > > In this way you'll at least stop using all lines and metros and the > like. I am not entirely sure that having a receive immediately > connected to a [spigot 0] has any computational expense, but if I'm > measuring things correctly they don't. So no need to shut off > receives, just send them to a closed gate > > best, > > J > > On Thu, Sep 29, 2011 at 10:30 PM, Ingo wrote: > >> Why would you have control messages going if switch~ is off? > > > > Because the voice gets assigned to a certain midi channel when it > receives a > > [noteon] and has to keep receiving all midi controllers on that channel > > until the envelope release has finished. Then the next voice will play > on > > that same midi channel. There is nothing that cuts off the control > inlets or > > [send/receive]s automatically because the audio gets switched off. > > So when you play 16 notes in a row all 16 voices are set up to receive > > control data on that particular midi channel. Everything in the control > > domain, like LFOs, [metro]s and [line]s keep running and keep > calculating > > pitch, volume, filter offsets and so on ... > > > > Turning off the [receive]s would be very complicated if not impossible > which > > is why they need to be avoided wherever it can be done. But all of the > wired > > inlets can be cut off manually together with the [switch~] and turned > back > > on when the next note will play that voice. On top of it all 500 > parameters > > need to be updated to the current state of the external control input > and > > the current preset data when played anew. > > > > Ingo > > > > > >> -Ursprüngliche Nachricht- > >> Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] > >> Gesendet: Donnerstag, 29. September 2011 19:56 > >> An: Ingo > >> Cc: Jonathan Wilkes; Pd List > >> Betreff: Re: [PD] Fwd: Variable number of objects? > >> > >> On Thu, Sep 29, 2011 at 1:41 PM, Ingo wrote: > >> > One shouldn't underestimate the cpu load when several hundreds of > midi > >> > controllers per second are modulating hundreds of parameters and the > get > >> > multiplied by 16 voices constantly because the control messages are > >> still > >> > active all of the time. > >> > >> Why would you have control messages going if switch~ is off? > >> > >> J > >> > >> > >> > > >> > Ingo > >> > > >> > > >> >> - Original Message - > >> >> > From: Ingo > >> >> > To: 'Roman Haefeli' ; 'Ludwig Maes' > >> >> > >> >> > Cc: 'Pd List' > >> >> > Sent: Thursday, September 29, 2011 5:33 AM > >> >> > Subject: Re: [PD] Fwd: Variable number of objects? > >> >> > > >> >> > Actually, I just tried again to simply copy a couple of voices and > it > >> >> only > >> >> > took a fraction of a second with a very short dropout - even with > the > >> >> dsp > >> >> > on. > >> >> > > >> >> > I have recently installed Natty instead of Lucid on a new machine. > >> Maybe > >> >> it > >> >> > has something to do with realloc that Mathieu mentioned. > >> >> > > >> >> > So it looks like dynamic
Re: [PD] Fwd: Variable number of objects?
> Why would you have control messages going if switch~ is off? Because the voice gets assigned to a certain midi channel when it receives a [noteon] and has to keep receiving all midi controllers on that channel until the envelope release has finished. Then the next voice will play on that same midi channel. There is nothing that cuts off the control inlets or [send/receive]s automatically because the audio gets switched off. So when you play 16 notes in a row all 16 voices are set up to receive control data on that particular midi channel. Everything in the control domain, like LFOs, [metro]s and [line]s keep running and keep calculating pitch, volume, filter offsets and so on ... Turning off the [receive]s would be very complicated if not impossible which is why they need to be avoided wherever it can be done. But all of the wired inlets can be cut off manually together with the [switch~] and turned back on when the next note will play that voice. On top of it all 500 parameters need to be updated to the current state of the external control input and the current preset data when played anew. Ingo > -Ursprüngliche Nachricht- > Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] > Gesendet: Donnerstag, 29. September 2011 19:56 > An: Ingo > Cc: Jonathan Wilkes; Pd List > Betreff: Re: [PD] Fwd: Variable number of objects? > > On Thu, Sep 29, 2011 at 1:41 PM, Ingo wrote: > > One shouldn't underestimate the cpu load when several hundreds of midi > > controllers per second are modulating hundreds of parameters and the get > > multiplied by 16 voices constantly because the control messages are > still > > active all of the time. > > Why would you have control messages going if switch~ is off? > > J > > > > > > Ingo > > > > > >> - Original Message - > >> > From: Ingo > >> > To: 'Roman Haefeli' ; 'Ludwig Maes' > >> > >> > Cc: 'Pd List' > >> > Sent: Thursday, September 29, 2011 5:33 AM > >> > Subject: Re: [PD] Fwd: Variable number of objects? > >> > > >> > Actually, I just tried again to simply copy a couple of voices and it > >> only > >> > took a fraction of a second with a very short dropout - even with the > >> dsp > >> > on. > >> > > >> > I have recently installed Natty instead of Lucid on a new machine. > Maybe > >> it > >> > has something to do with realloc that Mathieu mentioned. > >> > > >> > So it looks like dynamic patching of voices isn't "that" much of a > >> > problem > >> > here anymore. It still takes 7-8 seconds to create 16 voices in my > case > >> with > >> > the dsp off (12 with the dsp on) but that's still faster than > restarting > >> the > >> > patch. I would never have checked again if nobody would have > mentioned > >> it. > >> > > >> > I have attached a patch that I used for testing. These voices were > >> receiving > >> > their input with [receive] so no connections were needed. If you are > >> using > >> > wired inlets you will have to dynamically add the connections of > course. > >> > > >> > I added a cut & paste at the end because for some reasons the voices > >> > didn't > >> > get initialized correctly. Not sure if this is needed for other > >> > voice-abstractions. > >> > > >> > Ingo > >> > > >> > > >> >> -Ursprüngliche Nachricht- > >> >> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im > Auftrag > >> von > >> >> Roman Haefeli > >> >> Gesendet: Donnerstag, 29. September 2011 08:36 > >> >> An: Ludwig Maes > >> >> Cc: Pd List > >> >> Betreff: Re: [PD] Fwd: Variable number of objects? > >> >> > >> >> On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: > >> >> > > >> >> > > >> >> > -- Forwarded message -- > >> >> > From: Ludwig Maes > >> >> > Date: 28 September 2011 19:29 > >> >> > Subject: Re: [PD] Variable number of objects? > >> >> > To: Ingo > >> >> > > >> >> > > >> >> > I actually meant more in general, also for non-~ signals (i.e. > also > >> >> > control rate .pd patches). I referred to polysynth such that > people &g
Re: [PD] Fwd: Variable number of objects?
> What happens if you just have the maximum number of voices you think you'd > ever need and [switch~] them on and off as needed? > > Since you have a large patch, I'd be curious to know how much memory is > taken up by having the switched off voices just sitting there. > > -Jonathan That's what I am doing anyway. Memory is not an issue. There is obviously no change in memory by simply switching the voices on or off. After I got most of the control stuff as well as a large number of the [receive] objects out of the way the patch doesn't need that much cpu time at all unless the voices are turned on and playing. Now that the switched off voices are not hardly doing anything anymore there is no more need to adjust the voice number as it was the case before I got rid of a whole bunch of [receive] objects and cut most of the control messages when the [switch~] object gets turned off. In certain cases I can limit the voice number with different [poly] objects. One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Ingo > - Original Message - > > From: Ingo > > To: 'Roman Haefeli' ; 'Ludwig Maes' > > > Cc: 'Pd List' > > Sent: Thursday, September 29, 2011 5:33 AM > > Subject: Re: [PD] Fwd: Variable number of objects? > > > > Actually, I just tried again to simply copy a couple of voices and it > only > > took a fraction of a second with a very short dropout - even with the > dsp > > on. > > > > I have recently installed Natty instead of Lucid on a new machine. Maybe > it > > has something to do with realloc that Mathieu mentioned. > > > > So it looks like dynamic patching of voices isn't "that" much of a > > problem > > here anymore. It still takes 7-8 seconds to create 16 voices in my case > with > > the dsp off (12 with the dsp on) but that's still faster than restarting > the > > patch. I would never have checked again if nobody would have mentioned > it. > > > > I have attached a patch that I used for testing. These voices were > receiving > > their input with [receive] so no connections were needed. If you are > using > > wired inlets you will have to dynamically add the connections of course. > > > > I added a cut & paste at the end because for some reasons the voices > > didn't > > get initialized correctly. Not sure if this is needed for other > > voice-abstractions. > > > > Ingo > > > > > >> -Ursprüngliche Nachricht- > >> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > >> Roman Haefeli > >> Gesendet: Donnerstag, 29. September 2011 08:36 > >> An: Ludwig Maes > >> Cc: Pd List > >> Betreff: Re: [PD] Fwd: Variable number of objects? > >> > >> On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: > >> > > >> > > >> > -- Forwarded message -- > >> > From: Ludwig Maes > >> > Date: 28 September 2011 19:29 > >> > Subject: Re: [PD] Variable number of objects? > >> > To: Ingo > >> > > >> > > >> > I actually meant more in general, also for non-~ signals (i.e. also > >> > control rate .pd patches). I referred to polysynth such that people > >> > would see more easily what I meant. Are there really no such > >> > primitives? That seems like quite a restriction... > >> > > >> > How can that take 10 seconds?? I dont see what would cause such a > huge > >> > overhead, i'd expect an increase in computations & memory > > though (say > >> > from 10 voices to 11: 10% increase in cpu workload & ram dedicated > > to > >> > these voices..., I fail to see what would necessitate a long > >> > initialization...) > >> > > >> > also, how is it done even with the long delays? > >> > > >> > >> > >> As I understand it, the whole DSP is recompiled whenever it is > changed. > >> So, if you have a very large patch (and Ingo seems to be an expert in > >> very large patches) and you create another voice, it's easily possible > >> to eat up quite some time. > >> > >> Also, it's probably much slower the first time, if the voice > > abstraction > >> is built of many
Re: [PD] Fwd: Variable number of objects?
I made some more changes and added some help information to the voice creation patch so you can simple use a float to add voices and 0 to clear all voices. There are wired inlets for the voices now. Hope it's helpful for anybody! Ingo > -Ursprüngliche Nachricht- > Von: Ingo [mailto:i...@miamiwave.com] > Gesendet: Donnerstag, 29. September 2011 12:02 > An: 'Ingo'; 'Roman Haefeli'; 'Ludwig Maes' > Cc: 'Pd List' > Betreff: AW: [PD] Fwd: Variable number of objects? > > I just added the [; pd dsp 0( when starting to creat voices to speed it up > and eliminated the 17 voices limit of the patch. > > Maybe it's useful for somebody. > > Ingo > > > -Ursprüngliche Nachricht- > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > Ingo > > Gesendet: Donnerstag, 29. September 2011 11:33 > > An: 'Roman Haefeli'; 'Ludwig Maes' > > Cc: 'Pd List' > > Betreff: Re: [PD] Fwd: Variable number of objects? > > > > Actually, I just tried again to simply copy a couple of voices and it > only > > took a fraction of a second with a very short dropout - even with the > dsp > > on. > > > > I have recently installed Natty instead of Lucid on a new machine. Maybe > > it > > has something to do with realloc that Mathieu mentioned. > > > > So it looks like dynamic patching of voices isn't "that" much of a > problem > > here anymore. It still takes 7-8 seconds to create 16 voices in my case > > with > > the dsp off (12 with the dsp on) but that's still faster than restarting > > the > > patch. I would never have checked again if nobody would have mentioned > it. > > > > I have attached a patch that I used for testing. These voices were > > receiving > > their input with [receive] so no connections were needed. If you are > using > > wired inlets you will have to dynamically add the connections of course. > > > > I added a cut & paste at the end because for some reasons the voices > > didn't > > get initialized correctly. Not sure if this is needed for other > > voice-abstractions. > > > > Ingo > > > > > > > -Ursprüngliche Nachricht- > > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > > von > > > Roman Haefeli > > > Gesendet: Donnerstag, 29. September 2011 08:36 > > > An: Ludwig Maes > > > Cc: Pd List > > > Betreff: Re: [PD] Fwd: Variable number of objects? > > > > > > On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: > > > > > > > > > > > > -- Forwarded message -- > > > > From: Ludwig Maes > > > > Date: 28 September 2011 19:29 > > > > Subject: Re: [PD] Variable number of objects? > > > > To: Ingo > > > > > > > > > > > > I actually meant more in general, also for non-~ signals (i.e. also > > > > control rate .pd patches). I referred to polysynth such that people > > > > would see more easily what I meant. Are there really no such > > > > primitives? That seems like quite a restriction... > > > > > > > > How can that take 10 seconds?? I dont see what would cause such a > huge > > > > overhead, i'd expect an increase in computations & memory though > (say > > > > from 10 voices to 11: 10% increase in cpu workload & ram dedicated > to > > > > these voices..., I fail to see what would necessitate a long > > > > initialization...) > > > > > > > > also, how is it done even with the long delays? > > > > > > > > > > > > > As I understand it, the whole DSP is recompiled whenever it is > changed. > > > So, if you have a very large patch (and Ingo seems to be an expert in > > > very large patches) and you create another voice, it's easily possible > > > to eat up quite some time. > > > > > > Also, it's probably much slower the first time, if the voice > abstraction > > > is built of many other abstractions, which need to be read from disk. > > > > > > But I guess you are right about the increase in CPU workload _after_ > the > > > DSP graph has been recompiled: A switch from 10 two 11 instances is > > > expected to show only an increase of 10% in CPU usage. > > > > > > It's been said, that often you can gain quite some time while turning >
Re: [PD] Fwd: Variable number of objects?
I just added the [; pd dsp 0( when starting to creat voices to speed it up and eliminated the 17 voices limit of the patch. Maybe it's useful for somebody. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Ingo > Gesendet: Donnerstag, 29. September 2011 11:33 > An: 'Roman Haefeli'; 'Ludwig Maes' > Cc: 'Pd List' > Betreff: Re: [PD] Fwd: Variable number of objects? > > Actually, I just tried again to simply copy a couple of voices and it only > took a fraction of a second with a very short dropout - even with the dsp > on. > > I have recently installed Natty instead of Lucid on a new machine. Maybe > it > has something to do with realloc that Mathieu mentioned. > > So it looks like dynamic patching of voices isn't "that" much of a problem > here anymore. It still takes 7-8 seconds to create 16 voices in my case > with > the dsp off (12 with the dsp on) but that's still faster than restarting > the > patch. I would never have checked again if nobody would have mentioned it. > > I have attached a patch that I used for testing. These voices were > receiving > their input with [receive] so no connections were needed. If you are using > wired inlets you will have to dynamically add the connections of course. > > I added a cut & paste at the end because for some reasons the voices > didn't > get initialized correctly. Not sure if this is needed for other > voice-abstractions. > > Ingo > > > > -Ursprüngliche Nachricht- > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > Roman Haefeli > > Gesendet: Donnerstag, 29. September 2011 08:36 > > An: Ludwig Maes > > Cc: Pd List > > Betreff: Re: [PD] Fwd: Variable number of objects? > > > > On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: > > > > > > > > > -- Forwarded message -- > > > From: Ludwig Maes > > > Date: 28 September 2011 19:29 > > > Subject: Re: [PD] Variable number of objects? > > > To: Ingo > > > > > > > > > I actually meant more in general, also for non-~ signals (i.e. also > > > control rate .pd patches). I referred to polysynth such that people > > > would see more easily what I meant. Are there really no such > > > primitives? That seems like quite a restriction... > > > > > > How can that take 10 seconds?? I dont see what would cause such a huge > > > overhead, i'd expect an increase in computations & memory though (say > > > from 10 voices to 11: 10% increase in cpu workload & ram dedicated to > > > these voices..., I fail to see what would necessitate a long > > > initialization...) > > > > > > also, how is it done even with the long delays? > > > > > > > > > As I understand it, the whole DSP is recompiled whenever it is changed. > > So, if you have a very large patch (and Ingo seems to be an expert in > > very large patches) and you create another voice, it's easily possible > > to eat up quite some time. > > > > Also, it's probably much slower the first time, if the voice abstraction > > is built of many other abstractions, which need to be read from disk. > > > > But I guess you are right about the increase in CPU workload _after_ the > > DSP graph has been recompiled: A switch from 10 two 11 instances is > > expected to show only an increase of 10% in CPU usage. > > > > It's been said, that often you can gain quite some time while turning > > off DSP during dynamic instantiation. But I guess, this makes only a > > difference when performing several instantiations at the same time. When > > DSP is on, each cycle would cause a complete DSP graph recompilation, > > whereas when DSP is off, it's only recompiled once (after turning it on > > again). > > > > > > > > Roman > > > > > > > > ___ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list #N canvas 609 0 565 681 10; #X text 193 513 pos left; #X text 251 513 pos top; #X obj 244 568 pack f f f; #X msg 131 554 selectall; #X msg 101 554 cut; #X msg 61 554 paste; #X obj 45 608 s reset_system_delay; #X obj 260 223 f; #X obj 292 223 + 1; #X obj 228 280 sel; #X obj 244 208 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 228 307 0; #X obj 160 307 spigot; #X obj 262 435 t b f f; #X obj 272 462 * 20; #
Re: [PD] Fwd: Variable number of objects?
Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't "that" much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut & paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Roman Haefeli > Gesendet: Donnerstag, 29. September 2011 08:36 > An: Ludwig Maes > Cc: Pd List > Betreff: Re: [PD] Fwd: Variable number of objects? > > On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: > > > > > > -- Forwarded message -- > > From: Ludwig Maes > > Date: 28 September 2011 19:29 > > Subject: Re: [PD] Variable number of objects? > > To: Ingo > > > > > > I actually meant more in general, also for non-~ signals (i.e. also > > control rate .pd patches). I referred to polysynth such that people > > would see more easily what I meant. Are there really no such > > primitives? That seems like quite a restriction... > > > > How can that take 10 seconds?? I dont see what would cause such a huge > > overhead, i'd expect an increase in computations & memory though (say > > from 10 voices to 11: 10% increase in cpu workload & ram dedicated to > > these voices..., I fail to see what would necessitate a long > > initialization...) > > > > also, how is it done even with the long delays? > > > > > As I understand it, the whole DSP is recompiled whenever it is changed. > So, if you have a very large patch (and Ingo seems to be an expert in > very large patches) and you create another voice, it's easily possible > to eat up quite some time. > > Also, it's probably much slower the first time, if the voice abstraction > is built of many other abstractions, which need to be read from disk. > > But I guess you are right about the increase in CPU workload _after_ the > DSP graph has been recompiled: A switch from 10 two 11 instances is > expected to show only an increase of 10% in CPU usage. > > It's been said, that often you can gain quite some time while turning > off DSP during dynamic instantiation. But I guess, this makes only a > difference when performing several instantiations at the same time. When > DSP is on, each cycle would cause a complete DSP graph recompilation, > whereas when DSP is off, it's only recompiled once (after turning it on > again). > > > > Roman > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list #N canvas 609 0 565 676 10; #X text 193 513 pos left; #X text 251 513 pos top; #X obj 244 568 pack f f f; #X msg 117 554 selectall; #X msg 87 554 cut; #X msg 47 554 paste; #X obj 30 608 s reset_system_delay; #X obj 262 243 f; #X obj 294 243 + 1; #X obj 228 280 sel; #X obj 246 228 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 228 307 0; #X obj 160 307 spigot; #X obj 262 435 t b f f; #X obj 272 462 * 20; #X msg 406 372 clear; #X obj 30 527 t b b b b; #X obj 193 124 f; #X text 305 513 argument (voice number); #X text 277 108 set number of voices; #X obj 298 16 loadbang; #X obj 247 110 nbx 2 14 1 24 0 1 empty empty empty 0 -8 0 10 -261682 -1 -1 4 256; #X msg 214 531 30; #X obj 272 482 + 20; #N canvas 268 529 331 383 voicecanvas 1; #X restore 26 18 pd voicecanvas; #X obj 406 392 s pd-voicecanvas; #X obj 273 48 bng 15 250 50 0 empty empty add_voices -52 7 1 9 -257985 -1 -1; #X obj 47 581 s pd-voicecanvas; #X obj 244 608 s pd-voicecanvas; #X msg 244 588 obj \$1 \$2 samplevoice \$3; #X obj 30 507 pipe 100; #X text 20 279 pipe can be set faster; #X text 242 623 send to ; #X obj 298 63 t b b b; #X obj 337 244 nbx 2 14 0 16 0 0 empty empty empty 0 -8 0 10 -261682 -1 -1 0 256; #X obj 262 295 +; #X obj 289 402 s pd-voicecanvas; #X msg 289 382 obj 30 10 inlet; #X obj 262 315 t f f; #X obj 289 355 t b b; #X obj 289 335 sel 1; #X msg 262 201 0; #
Re: [PD] throw~ / catch~ versus send~ / receive~
I would assume this one block delay could be avoided by cut and undo of the [catch~] object after creating new [throw~] objects. Right? But how can you time it if they are in different abstractions? Ingo _ Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Björn Eriksson Gesendet: Donnerstag, 29. September 2011 00:20 An: Lorenzo Sutton; pd-list@iem.at Betreff: Re: [PD] throw~ / catch~ versus send~ / receive~ Thanks for the info and pointer! Was by that also getting aware about the possible added delay "When you send a signal to a point that is earlier in the sorted list of tilde objects, the signal doesn't get there until the next cycle of DSP computation, one block later; so your signal will be delayed by one block (1.45 msec by default.)" Can be good to know! /Björn 2011/9/28 Lorenzo Sutton Hi Björn, On 28/09/2011 15:27, Björn Eriksson wrote: [...] what are the differences between throw~ / catch~ and send~ / receive~ ? For me they seem to work equally well, either as "bus" sending or single audio signal send. >From the Pd Documentation [1]: "There can be many throw~ objects associated with a single catch~, but a throw~ can't talk to more than one catch~. ... Send~ just saves a signal which may then be receive~d any number of times; but a receive~ can only pick up one send~ at a time (but you can switch between send~s if you want.)" Ciao, Lorenzo [1] http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s4.5 Maybe I am doing wrong when I´m summing audiosignals together into a send~ object just by patching them together and should use the throw~object instead, but just curious on why and how?// Thankful for thoughts on this.. All the best, Björn Eriksson ___ 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] Variable number of objects?
Well, as I said in my case the voices are very complex. There are hundreds of audio objects in each voice. It takes a lot of time to adjust all of the signal flow and reallocate the memory I guess. Control objects shouldn't be such a big problem. Ingo Von: Ludwig Maes [mailto:ludwig.m...@gmail.com] Gesendet: Mittwoch, 28. September 2011 19:30 An: Ingo Betreff: Re: [PD] Variable number of objects? I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations & memory though (say from 10 voices to 11: 10% increase in cpu workload & ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? On 28 September 2011 18:33, Ingo wrote: To my experience there will be definitely audio dropouts with dynamic voice creation. In the case of my rather complex patch (with currently only 8 voices) I have to wait up to ten seconds until the patch is ready again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow. Simpler synth voices might be faster, though. I think it is much better to create as many voices as needed beforehand and turn unused voices off with the [switch~] object. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects? Im not sure what the best way is to instantiate variable number of objects, for example consider polysynth.pd: Theres a fixed number of manually placed voices, suppose I want to have the top patch to contain a counter through which one may increase or decrease the number of voices, how would I go about that (without manually placing a load of voices and disabling them...)? Whats the vanilla way to do this? Whats the pd-extended way to do this? ... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Variable number of objects?
To my experience there will be definitely audio dropouts with dynamic voice creation. In the case of my rather complex patch (with currently only 8 voices) I have to wait up to ten seconds until the patch is ready again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow. Simpler synth voices might be faster, though. I think it is much better to create as many voices as needed beforehand and turn unused voices off with the [switch~] object. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects? Im not sure what the best way is to instantiate variable number of objects, for example consider polysynth.pd: Theres a fixed number of manually placed voices, suppose I want to have the top patch to contain a counter through which one may increase or decrease the number of voices, how would I go about that (without manually placing a load of voices and disabling them...)? Whats the vanilla way to do this? Whats the pd-extended way to do this? ... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Actually, packing an id before the actual data and using a route object to distribute all separate destinations from one single [receive] -> [route] -> parameters would do the trick. Maybe that's what you meant? I just cannot picture a [route] object with up to 500 outlets, yet. But there might be ways to organize it using a small number of [receive] and a small number of [route] and sub-[route] objects. However, it would take just as much time to rewrite an existing patch like this as it takes to hardwire the sends. I still think that these considerations need to be made when starting to write any kind of code because problems only start showing up when it's almost too late. Once the patch gets kinda huge fixing will become very time consuming. Optimizing any code to the least amount of parsing data/messages around is the key for doing any complex patches. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Ingo > Gesendet: Freitag, 16. September 2011 16:42 > An: 'Claude Heiland-Allen'; pd-list@iem.at > Betreff: Re: [PD] pduino rewrite > > Hi Claude, > > > > When I started I thought it was very convenient to use wireless > > > [send/receive] objects to send midi data to the sample-voices (which > it > > is). > > [snip] > > > Sending 3,000 messages to 8,000 [receive] objects adds up to 24 > million > > > times per second that the individual [receive] objects had to check > > whether > > > the message was meant to be for them or not. > > [snip] > > > The second fix was > > > to replace the wireless sends with hard wired patch chords. > > > > Faced with this scenario I would probably have tried dynamic sends, so > > the data determines which receive gets the message. > > > > For example: > > > > ... > > | > > [pack f f f f f f] > > | > > [ ; r-$1-$2-$3 $4 $5 $6 ( > > > > > > [r r-1-4-7] > > | > > [unpack f f f] > > | > > ... > > > > [r r-27-63-49] > > | > > [unpack f f f] > > | > > > > That would imply that you know which midi CC message gets there when since > the left inlet of [pack] needs to be banged. Or it would be delayed until > the left inlet receives a new message (if at all). Or you would have to > bang > the left inlet every time another one comes in. That would even multiply > the > data transfer. > Last solution would be a fixed send timing every couple of milliseconds. > That would multiply the average data transfer and lower the timing > resolution. > > > And using nested abstractions you could create the receives based on > > $args > > $args have to listen to all sent messages also. You are simply expanding > the > name with the $arg. When you have 10 voices all [receive]s of all 10 > voices > will have to listen for every [send] message to determine whether it is > for > them or not. Doesn't matter if the name starts with "$0-". > > > and if you need lots of voices you could use dynamic patching to > > instantiate them. > > To initialize sample-voices like the ones I am using Pd takes about ten > seconds. If you want to play a piano chord that has one note more than > current voices are present you don't really want to wait 10 seconds, do > you? > And afterwards are you going to erase that voice again? This would again > interrupt the audio stream. > > Anyway audio calculation can be turned off with the [switch~] object. > [receive] objects cannot be made inactive ever. The only way to do this > would be to split up the voices over several independent patches which > communicate over [netsend/netreceive] or [osc]. This makes audio > communication very difficult and it would be very hard to keep all of > those > thousands of tables updated in all patches. > > It's just simply more efficient to address the data directly by wired > connections only to the destination that needs the data. Looks messy but > works better! > > Ingo > > > ___ > 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] pduino rewrite
Hi Claude, > > When I started I thought it was very convenient to use wireless > > [send/receive] objects to send midi data to the sample-voices (which it > is). > [snip] > > Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million > > times per second that the individual [receive] objects had to check > whether > > the message was meant to be for them or not. > [snip] > > The second fix was > > to replace the wireless sends with hard wired patch chords. > > Faced with this scenario I would probably have tried dynamic sends, so > the data determines which receive gets the message. > > For example: > > ... > | > [pack f f f f f f] > | > [ ; r-$1-$2-$3 $4 $5 $6 ( > > > [r r-1-4-7] > | > [unpack f f f] > | > ... > > [r r-27-63-49] > | > [unpack f f f] > | > That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution. > And using nested abstractions you could create the receives based on > $args $args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with "$0-". > and if you need lots of voices you could use dynamic patching to > instantiate them. To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream. Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches. It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
To make sure boards that are larger than 56 digital in pins you should copy a couple more of these objects to go up to 128. Of course since [&] and [>>] seems to be slightly faster that would be the choice. To be even more efficient the object [pd route digital/analog] should be bypassed by adding the addresses [144 145 146 ... 151] to the route object inside the parent patch making it [route 249 240 144 145 146 147 148 149 150 151]. The last outlet goes into [pd route digital/analog]. The [route 0 1 2 3 4 5 6 7] inside the [pd digital messages] should be replace by 8 individual inlets. BTW you could keep going on with this forever ... All I wanted originally was to get the correct messages coming out of the patch ... Ingo > -Ursprüngliche Nachricht- > Von: Roman Haefeli [mailto:reduz...@gmail.com] > Gesendet: Freitag, 16. September 2011 14:44 > An: Ingo > Cc: 'Hans-Christoph Steiner'; pd-list@iem.at > Betreff: Re: AW: AW: AW: AW: [PD] pduino rewrite > > On Fri, 2011-09-16 at 14:05 +0200, Ingo wrote: > > > Wow, I just compared your version of [pd digital message] with mine > and > > > yours takes only 180ms to process 100 of messages, while mine uses > > > over 8s. > > > Frankly, I wouldn't have expected such a big difference Let me dig > > > into this. > > > > > > Roman > > > > > > That's more than I would have expected, too! > > I would have been guessing it could be up to 10x as fast but not 50x. > > I think I'm going to put your much more efficient version into the git > version. > > Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] multiple arduinos
> > I just tried to open the help file on Windows XP and Natty and it > > crashes Pd on both platforms. > hm that's a pity - anyone else similar experience? > any hints how to reproduce this? Tried it again right now and it's working. Might have been a server issue. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Roman, > Frankly, I'm not yet convinced that those little improvements in > [arduino] will significantly improve the overall Pd performance. Here's the reason why I started really to simplify any patch, no matter if audio or control objects: I have been programming for about 4 years on one single patch (fulltime - only with breaks to get the hardware/OS going and sampling/editing sampled instruments). You can imagine the amount of code that is in the patch by now. When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). At a certain point (about 2 years ago) the machine was completely overloaded! Then I measured that a EWI-USB wind controller can send up to 500 midi CC messages per second. I had a function that could multiply the messages to six different midi channels. That makes it 3,000 messages floating around. The sample voices have at least 500 [receive] objects (there are close to 500 parameters per voice). There were 16 voices which adds up to 8,000 [receive] objects. Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. That should be as much data shifting around only for checking [receive] objects as it would take to move the data of several hundreds of audio channels around. The first fix was easy: assigning the parameter to receive from midi Ch01 if voices are stacked. That cut the message transfer by 6. The second fix was to replace the wireless sends with hard wired patch chords. That took care of most of the rest. The machine was working again. Unfortunately this second fix took 3-4 full months!!! This is when I decided to think about efficiency in running mode first. If you have a piece of code that has to check between 10 different options and in a certain case only two options are available then it is worth it copying the object and take out all unnecessary options. It's more work while programming but it saves in this particular example several hundred percent cpu time when running. When such a programming style is used consistently I am sure you can get at least double or more of the performance of a computer. Even with messages where you would think they are not too heavy. Ingo > -Ursprüngliche Nachricht- > Von: Roman Haefeli [mailto:reduz...@gmail.com] > Gesendet: Freitag, 16. September 2011 11:32 > An: Ingo > Cc: 'Hans-Christoph Steiner'; pd-list@iem.at > Betreff: Re: AW: AW: AW: [PD] pduino rewrite > > On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: > > > The [change -1] is a great idea, I just committed that to bytemask.pd > > > and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem > > > quite labor-intensive, but they work. I think it would work better to > > > use multiple instances of [debytemask]. > > > > > > .hc > > > > Not sure what you mean by "labor-intensive", Hans. Are you talking about > > manually changing 8 numbers per object (which took me less than 1 minute > for > > 56 channels) or are you talking about cpu processing? > > > > Which leads me to the next question: is the Boolean approach using [& 4] > and > > [>> 2] more cpu friendly than using [mod 8] and [div 4]? > > I was told that it is. Bit shifting and bit mask matching is supposed to > be faster than integer division and modulo with an arbitrary (inclusive > non-power-of-two integers). > However, I can't tell you whether they are really faster in the real > world. But you should be able to test it in your own setup with > [realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million > numbers in 0 logical time, stop [realtime]. Do the same with a [& 4]-[>> > 2] chain and compare the results. > > > I don't know how Pd > > handles such calculations and how it talks to the cpu. I'd be really > very > > interested to find out if there is a difference. > > > > > > Since the pin numbers are predefined when you are using a [route] object > to > > sort out the groups I don't see the point why the pin number should be > > calculated again (in this case of multiple instances). This is why I > > hardcoded them into the message boxes. > > > > I put the two approaches next to each other to see how much simpler my > > approach is object wise and calculation wise. Still with the question > mark > > which calculation method is more cpu friendly. Anyway changing [mod 8] > and > > [div 4] to [& 4] and [>> 2] shouldn't take more than a minute. > > You could also test the whole [pd digital message] subpatch wi
Re: [PD] pduino rewrite
> Wow, I just compared your version of [pd digital message] with mine and > yours takes only 180ms to process 100 of messages, while mine uses > over 8s. > Frankly, I wouldn't have expected such a big difference Let me dig > into this. > > Roman That's more than I would have expected, too! I would have been guessing it could be up to 10x as fast but not 50x. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
> The [change -1] is a great idea, I just committed that to bytemask.pd > and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem > quite labor-intensive, but they work. I think it would work better to > use multiple instances of [debytemask]. > > .hc Not sure what you mean by "labor-intensive", Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [& 4] and [>> 2] more cpu friendly than using [mod 8] and [div 4]? I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [& 4] and [>> 2] shouldn't take more than a minute. The main difference to Romans approach is that it uses more fixed code to end up doing less when actually working. BTW I think Romans approach makes generally more sense for most cases since it is scalable and does not need any different code for any number of pins (up to 128 in the current version) which makes it much simpler to use. I have attached a patch that shows the difference between the two debyte methods. Ingo #N canvas 317 0 1025 801 10; #X obj 238 619 cnv 15 370 140 empty empty empty 20 12 0 14 -262130 -66577 0; #X floatatom 253 633 5 0 255 0 - - -; #X floatatom 253 685 5 0 0 0 - - -; #X floatatom 303 685 5 0 0 0 - - -; #X floatatom 253 731 5 0 0 0 - - -; #X floatatom 303 731 5 0 0 0 - - -; #X obj 253 665 mod 8; #X obj 253 704 div 4; #X obj 303 665 & 4; #X obj 303 705 >> 2; #X text 362 628 Question:; #X obj 540 79 cnv 15 350 100 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 659 376 cnv 15 170 180 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 190 582 outlet; #X obj 190 55 route 0 1 2 3 4 5 6; #X obj 190 28 inlet; #X obj 690 495 +; #X msg 690 535 digital \$1 \$2; #X obj 690 515 pack float float; #X obj 690 378 unpack float float; #X obj 690 82 t a a; #X msg 717 102 \$1; #X msg 690 102 \$2; #X obj 690 55 route 0 1 2 3 4 5 6; #X obj 690 28 inlet; #X obj 550 159 trigger float float float float float float float float ; #X obj 690 582 outlet; #X obj 659 619 cnv 15 170 140 empty empty empty 20 12 0 14 -232576 -66577 0; #X text 668 663 There is no need to; #X obj 959 193 cnv 15 50 50 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 972 199 & 15; #X obj 972 220 * 8; #X text 668 726 selects this pin group.; #X text 668 711 The route object already; #X text 362 648 is the 1st calculation using [mod] and; #X text 362 663 [div] heavier on cpu cycles than [& 4]; #X text 362 678 and [>> 2] due to different processor; #X text 362 693 instructions?; #X text 687 6 debyte; #X text 668 691 defined by the firmata.; #X text 668 676 calculate the pin number; #X text 668 628 The objects marked here; #X text 668 643 are not necessary.; #X obj 336 722 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 336 682 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 4 188 cnv 15 920 120 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 370 206 mod 128; #X obj 310 206 mod 64; #X obj 250 206 mod 32; #X obj 190 206 mod 16; #X obj 130 206 mod 8; #X obj 70 206 mod 4; #X obj 10 206 mod 2; #X obj 70 226 div 2; #X obj 430 226 div 128; #X obj 130 226 div 4; #X obj 190 226 div 8; #X obj 250 226 div 16; #X obj 310 226 div 32; #X obj 370 226 div 64; #X obj 10 246 change -1; #X obj 70 246 change -1; #X obj 130 246 change -1; #X obj 190 246 change -1; #X obj 250 246 change -1; #X obj 310 246 change -1; #X obj 370 246 change -1; #X obj 430 246 change -1; #X msg 10 266 digital 0 \$1; #X msg 70 286 digital 1 \$1; #X msg 130 266 digital 2 \$1; #X msg 190 286 digital 3 \$1; #X msg 250 266 digital 4 \$1; #X msg 310 286 digital 5 \$1; #X msg 370 266 digital 6 \$1; #X msg 430 286 digital 7 \$1; #X obj 430 206 mod 256; #X msg 550 264 0 \$1; #X msg 596 284 1 \$1; #X msg 643 265 2 \$1; #X msg 690 284 3 \$1; #X msg 736 266 4 \$1; #X msg 783 284 5 \$1; #X msg 830 267 6 \$1; #X msg 877 284 7 \$1; #X obj 550 206 & 1; #X obj 596 205 & 2; #X obj 643 205 & 4; #X obj 690 205 & 8; #X obj 736 205 & 16; #X obj 783 205 & 32; #X obj 830 205 & 64; #X obj 877 205 & 128; #X obj 596 225 >> 1; #X obj 643 225 >> 2; #X obj 690 225 >> 3; #X obj 736 225 >> 4; #X obj 783 225 >> 5; #X obj 830 225 &g
Re: [PD] pduino rewrite
Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. Ingo > -Ursprüngliche Nachricht- > Von: Hans-Christoph Steiner [mailto:h...@at.or.at] > Gesendet: Donnerstag, 15. September 2011 17:48 > An: Ingo > Cc: 'Roman Haefeli'; pd-list@iem.at > Betreff: Re: AW: [PD] pduino rewrite > > On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: > > > Interesting. How did you quantify the amount of message transfers? > What > > > makes it differ so much, like you say? > > > > I simply (roughly) counted the numbers of objects the calculation > including > > all sub processes have to pass until you get the final result. > > (Unfortunately I cannot tell how heavy each of these calculations is > > compared to another one.) > > > > I started this a while ago since I am running my machines always at the > very > > limit that they can handle. Which is why I started cutting down the > number > > of processes needed to get something done wherever possible. Saving 20% > of > > the calculations in a machine that's at the limit can make quite a > > difference. Of course it's the audio processes that are heavier than the > > control processes. > > > > I remember a discussion here a while ago about how heavy the actual > message > > transfer is. So keeping calculations as simple and straight forward all > of > > the time will keep the machines from getting overloaded earlier than > > necessary. Which again reminds me that I have to redo lots of old stuff > for > > efficiency - never ending story! > > > > Ingo > > If you want efficiency in this object, you should implement it in C. > That should not be hard to do since the Firmata code is C++, but coded > mostly in a C style. So you can get all of the parsing and message > generating code from Firmata.cpp and StandardFirmata.pde, and make a > compiled object out of it. > > And Ingo, if you implement a fixed the [debytemask] approach, I'll > included it in the Pduino arduino.pd. > > .hc #N canvas 504 92 321 208 10; #N canvas 606 345 294 266 digital_messages 1; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 1386 0 534 360 resolve-bits_32-39 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 32 \$1; #X msg 80 216 digital 33 \$1; #X msg 140 196 digital 34 \$1; #X msg 200 216 digital 35 \$1; #X msg 260 196 digital 36 \$1; #X msg 320 216 digital 37 \$1; #X msg 380 196 digital 38 \$1; #X msg 440 216 digital 39 \$1; #X obj 440 129 mod 256; #X connect 0 0 24 0; #X connect 2 0 15 0; #X connect 3 0 14 0; #X connect 4 0 13 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 9 0; #X connect 8 0 16 0; #X connect 9 0 17 0; #X connect 10 0 23 0; #X connect 11 0 18 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 25 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 2 0; #X connect 24 0 3 0; #X connect 24 0 4 0; #X connect 24 0 5 0; #X connect 24 0 6 0; #X connect 24 0 8 0; #X connect 24 0 7 0; #X connect 24 0 33 0; #X connect 25 0 1 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 10 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 1386 0 534 360 resolve-bits_0-7 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj
Re: [PD] multiple arduinos
I just tried to open the help file on Windows XP and Natty and it crashes Pd on both platforms. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > olsen > Gesendet: Donnerstag, 15. September 2011 14:52 > An: tim vets > Cc: pd-list > Betreff: Re: [PD] multiple arduinos > > Hi > > if you're running on Linux check the [ADDITIONAL-INFOS] in the arduino- > help.pd on the upper right corner in the > pd-rewrite: https://github.com/reduzent/pduino > as mentioned below the infos you'll find there are basically from > http://answers.ros.org/answers/101/revisions/ > with this method you can connect the arduino within pd due to its serial > adress avoiding id-conflicts. > > hope this helps > ø > > > On 09/06/2011 09:27 PM, tim vets wrote: > > We have an installation running at www.verbekefoundation.com > <http://www.verbekefoundation.com> with two arduino's and > > pd for several years now. > > The only thing that fries now and then are the power supplies. > > iirc, it's just a matter of sending the right [devicename > ( to the two [comport], ( or [arduino] ?) objects. > > You can get those devicenames by doing "ls /dev/ttyU*", which will give > you something like /dev/ttyUSB0 and > > /dev/ttyUSB1, representing the two arduino's. > > (under the assumption that the newer arduino models still work the same > way.) > > gr, > > Tim > > > > 2011/9/6 FernandoG mailto:dataf...@gmail.com>> > > > > Hi > > > > Anybody knows if its posible to use multiple arduinos ( 2 or 3 > arduino mega) with the same pduino based puredata patch? > > > > Thanks! > > > > F > > > > ___ > > 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 > > -- > ETs DNA will not be televised > http://hasa-labs.org > > > ___ > 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] pduino rewrite
> Interesting. How did you quantify the amount of message transfers? What > makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
The reason why I didn't make an abstraction for the "debyte" is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. But as I had mentioned - I doubt that efficiency will play a role in just about any case for the arduino's digital pins. Ingo > -Ursprüngliche Nachricht- > Von: Roman Haefeli [mailto:reduz...@gmail.com] > Gesendet: Donnerstag, 15. September 2011 08:44 > An: Ingo > Cc: 'Hans-Christoph Steiner'; pd-list@iem.at > Betreff: Re: AW: [PD] pduino rewrite > > Hi Ingo > > Thanks for testing! > > On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote: > > Hi Roman, > > > > the new version works great! > > I'm glad to hear that. > > > I made myself some testing objects around it. > > Maybe that could be useful if you guys ever get around fixing the help > > patch. > > I'll have a look. Thanks. > > > I still think the version using individual debyte masks is far more > > efficient than this one. But as you pointed out this one is more > scalable > > and might take care of boards coming in the future (I have just seen a > mega > > clone with 70 or 72 digital inputs). > > > > Most people don't use incremental wheels timed to 1-2 ms - like I do - > > anyway. So efficiency shouldn't matter in 99.9% of the cases. > > I generally think it does matter. However, i don't have any concerns > that the additional table look up causes an efficiency problem. Table > lookups are usually very fast. > > It's probably a matter of taste, but I often find myself looking for an > 'algorithmic' solution instead of copying very similar code several > times around, even if the former is a bit less efficient than the > latter. > In this case, if using several [pd debytemask], it'd be nice to use an > abstraction instead. However, if the original [mapping/debytemask] would > be used, every (-1) instance would require a row of 8 [+ 8] objects, [+ > 16], [+ 24], etc. respectively. So it would either end up with a lot of > additional objects below all [debytemask] instances or multiple manually > crafted [pd debytemask] with each containing slightly different code (as > you implemented it) would be required. > The additional [pd polychange] with table lookup is made of just a > handful of objects. > > However, if it ever turns out, that in your setup the [arduino] > abstraction eats a significant amount of CPU power (what I really > doubt), I'll happily replace it by your version of [pd digital messages] > if it helps. > > And yes, the goal should be to cover also 'edge' cases like your > incremental wheel. The more use cases work well with Firmata / [arduino] > the better. > > Roman > > > > > > > -Ursprüngliche Nachricht- > > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > > Hans-Christoph Steiner > > > Gesendet: Mittwoch, 14. September 2011 22:33 > > > An: Roman Haefeli > > > Cc: pd-list@iem.at > > > Betreff: Re: [PD] pduino rewrite > > > > > > > > > As Ingo pointed out, one bug is that [mapping/debytemask] has the > > > [change] object for each outlet. So probably the way to fix this is > to > > > make a bunch of [mapping/debytemask] objects for all the possible > > > digital ports. > > > > > > [arduino] should only output on change of digital input, and it > receives > > > the digital information one byte/port at a time, i.e. 8 pins. Another > > > approach would be to have an array of all of the previous values which > > > are then compared to the current before outputting. > > > > > > .hc > > > > > > > > > On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: > > > > Hi Ingo > > > > > > > > Thanks for all your reports. > > > > > > > > Sorry that my replies sometimes only come a few days later. I'm > still > > > > willing to fix
Re: [PD] Transposing samples using MIDI numbers
You need to use [mtof] to convert the midi note number to the frequency first. [tabread4~] allows variable readout speed to play back transposed samples. Check the docs for some examples of [tabread4~] and samplers (3.audio.examples/B...). Ingo > Is there a way to transpose the sound of a sample [stored in a table] > to match a pitch/midi note number? > In my project, when a sample is played back [using tabplay~] I would > like something to tune that sample to say, midi note 69 or A 440. > I would like to be able to send this number to the transposing > function via a number box. > I am SOO close to realizing an idea, I just need this one crucial part. > > Thank you for your time, > Sebastian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Arduino - transmit serial data while running firmata?
Is it possible to transmit serial data from the computer through the serial port of Arduino to a serial lcd display while running firmata? And if yes, how? Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] question about echo and shell
I had it working on Ubuntu before. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > philippe boisnard > Gesendet: Sonntag, 11. September 2011 09:14 > An: Pd List > Betreff: [PD] question about echo and shell > > Hello > > I want to use this expression with [shell] > [echo "patatiptata" | tee -a /Applications/puredata/32- > espacedeportation/test.txt< > > no result ? > > when I try with terminal no problem. > why echo doesn't fonction with shell ? > > p ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting "NONE". This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option "Input-PullUp" should be added. The Arduino generally defaults to input. Selecting "NONE" at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command "analogIns X 0" (where the X stands for the pin number 0-5). The digital input pins need the command "digitalIns X 0" (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select "analog" as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed this bug for over two years! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Roman, Olsen and Hans, Here' a replacement object that fixes the behaviour that wrong "digital in" pins get recognized when more than the first 6 pins are used. I hope there is nothing else interfering with those pins anymore. The object "digital_messages" inside the patch should be placed here to replace the current object "digital messages": Arduino/convert to symbolic commands/ Please test if it is working on other systems! I have no idea if this works with the "mega" or not since I don't have one to test it. If anyone could check this out it would be great to know! Ingo #N canvas 0 0 450 300 10; #N canvas 702 733 318 273 digital_messages 0; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 2032 0 534 360 resolve-bits_32-39 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 32 \$1; #X msg 80 216 digital 33 \$1; #X msg 140 196 digital 34 \$1; #X msg 200 216 digital 35 \$1; #X msg 260 196 digital 36 \$1; #X msg 320 216 digital 37 \$1; #X msg 380 196 digital 38 \$1; #X msg 440 216 digital 39 \$1; #X connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 23 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 1 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 2032 0 534 360 resolve-bits_0-7 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 0 \$1; #X msg 80 216 digital 1 \$1; #X msg 140 196 digital 2 \$1; #X msg 200 216 digital 3 \$1; #X msg 260 196 digital 4 \$1; #X msg 320 216 digital 5 \$1; #X msg 380 196 digital 6 \$1; #X msg 440 216 digital 7 \$1; #X connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 23 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 1 0; #X restore 43 70 pd resolve-bits_0-7; #N canvas 2032 0 534 360 resolve-bits_8-15 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X
Re: [PD] pduino rewrite
Upon further testing I have found two bugs so far. On is in the firmata and the second one is in the [debytemask]. This makes fixing it a bit difficult. 1) firmata: instead of sending two values for a digital pin connected or disconnected it sends three. The first one should be the address and the second one the value for the group of 8 pins. There may be a reason why it sends another "0" at the end but that's not too important anyway. The bad thing is that when disconnecting a pin it sends these number five times (sometimes only three times) in a row while going back and forth between the last value and the current one. That's 15 bytes instead of two. (I am using an inc/dec wheel with the arduino and now I know why it doesn't respond like it should.) I havn't checked the analogue ins so far. 2) [debytemask]: there is only one debytemask for all addresses. This means - since there is a [change] object inside - there will be a wrong value when the same button of a different group of pins is pressed or released twice after each other. This could be still correct if all other pins of the group have identical values but creates "random" numbers if the other pins change. Not sure yet what else gets affected. I am going to try to fix the problem with the [debytemask] but I don't know if the firmata stuff has any big influence on it. I just added another 6 buttons to my remote (using all 12 digital and 6 analogue ins of the Diecimila / Duemilanove now) and the whole thing is going crazy now sending wrong stuff all over the place. Ingo > -Ursprüngliche Nachricht- > Von: Hans-Christoph Steiner [mailto:h...@at.or.at] > Gesendet: Freitag, 9. September 2011 16:41 > An: Ingo > Cc: 'Roman Haefeli'; 'pd-list' > Betreff: Re: [PD] pduino rewrite > > > I basically haven't used an Arduino in 2 years, so I am a poor candidate > for debugging this stuff. Roman and Olsen are much better candidates > for this job. > > The digital input pins are reported using the hardware-level ports, the > hardware is organized around pins 0-7 being one port, 8-15, another, and > 16-23 (analog pins) another. > > As for the pull-up resistor, you activate them just like you would in an > other code for an Atmel AVR chip: switch the pin mode to INPUT then set > that pin to HIGH (i.e. output a 1 to that pin). > > .hc > > > On Fri, 2011-09-09 at 11:34 +0200, Ingo wrote: > > I did test it with the Duemilanove. But I also tested Diecimila and Uno. > > To me the problem looks like "unfortunate design" in the firmata. The > > buttons 2-9 don't somehow connect the same 8-bit word. It might simply > be a > > bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I > > mentioned it. > > > > I have changed my arduino patch to get it to work for what I need with > the > > Diecimila to Uno. I don't like to submit any workarounds if I don't have > a > > mega available. I don't know how the rest of the pins are set up in > blocks. > > It might also break something else since I only use part of the > functions. > > > > I really think Hans is the one who should look into this problem to > > determine whether it is a pduino or firmata bug. > > > > I am really surprised that so few people have problems with this. Or > maybe > > they do and simply cannot figure out where the problem comes from? > > > > Ingo > > > > > > > -Ursprüngliche Nachricht- > > > Von: Roman Haefeli [mailto:reduz...@gmail.com] > > > Gesendet: Freitag, 9. September 2011 10:49 > > > An: Ingo > > > Cc: 'olsen'; 'pd-list' > > > Betreff: Re: AW: [PD] pduino rewrite > > > > > > On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: > > > > Hi Roman, > > > > > > > > I just messed around with the rewrite and - as you mentioned - you > > > didn't > > > > fix any of the bugs. > > > > > > > > I even think I send you a mail about the digital pins 2 & 3 and > provided > > > a > > > > fix for it here at the forum. Of course it's still there! > > > > > > > > About the other things: > > > > > > > > - The test patch has still no switches to turn on the pull up > resistors. > > > > > > > > - in Natty the comport number for USB0 is 32 that's not available in > the > > > > choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be > a > > > > better choice. At least this option of naming should be mentioned > > > somewhere > > &g
Re: [PD] pduino rewrite
I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like "unfortunate design" in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo > -Ursprüngliche Nachricht- > Von: Roman Haefeli [mailto:reduz...@gmail.com] > Gesendet: Freitag, 9. September 2011 10:49 > An: Ingo > Cc: 'olsen'; 'pd-list' > Betreff: Re: AW: [PD] pduino rewrite > > On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: > > Hi Roman, > > > > I just messed around with the rewrite and - as you mentioned - you > didn't > > fix any of the bugs. > > > > I even think I send you a mail about the digital pins 2 & 3 and provided > a > > fix for it here at the forum. Of course it's still there! > > > > About the other things: > > > > - The test patch has still no switches to turn on the pull up resistors. > > > > - in Natty the comport number for USB0 is 32 that's not available in the > > choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a > > better choice. At least this option of naming should be mentioned > somewhere > > in the test patch or help patch. (maybe I missed it somewhere?) > > > > - help-patch: there is no such thing as "PullDown". It's only "PullUp". > > It should be mentioned that pin 13 does not work for "Pull Up" due to > the > > built in LED and resistor. There should also be a short explanation > about > > PullUp resistors for beginners. > > > > - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent > a > > lot of time at the beginning making lots of complicated cable > connections > > because the help patch recommends connecting the pins to ground instead > of > > simply switching on the PullUp resistors. At least as long as you are > not at > > the very limit of your power supply. > > > > Since I only use the digital and analogue ins I didn't look any further. > So > > I can't say anything about the output stuff. > > > > The digital pins 2 & 3 should really be fixed sometime soon. I was > hoping > > you'd be getting some of these problems solved rather than putting a > grey > > background to the help patch (lol). > > Yo, it's very much a work in progress and yet the main goal was not > loose any functionality by getting rid of the externals. I did not > address any bugs yet, because I didn't experience any. > > I only have a arduino Diecimila to test here. So, I ask you again: The > problem you mentioned with pin 2 and 3, on which arduino board model do > you experience it? Also, if the problem is located in the firmware and > not in the [arduino] abstraction, I rather don't 'fix' it in the > [arduino] abstraction. > > Since you seem to have a strong interest on making it work for your > situation, I suggest to give you commit privileges to that repository. > You could send me your public key off-list and I would give you access > to that repository. > > Also, thanks for your other comments. Those are all valid points that > need to be addressed. > > (Actually, 'pduino rewrite' as thread was a bit too much a promise, it > should have read 'please test and report back'.) > > Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I forgot to mention: I tested with a Duemilanove. Ingo > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Ingo > Gesendet: Freitag, 9. September 2011 10:04 > An: 'Roman Haefeli'; 'olsen'; 'pd-list' > Betreff: Re: [PD] pduino rewrite > > Hi Roman, > > I just messed around with the rewrite and - as you mentioned - you didn't > fix any of the bugs. > > I even think I send you a mail about the digital pins 2 & 3 and provided a > fix for it here at the forum. Of course it's still there! > > About the other things: > > - The test patch has still no switches to turn on the pull up resistors. > > - in Natty the comport number for USB0 is 32 that's not available in the > choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a > better choice. At least this option of naming should be mentioned > somewhere > in the test patch or help patch. (maybe I missed it somewhere?) > > - help-patch: there is no such thing as "PullDown". It's only "PullUp". > It should be mentioned that pin 13 does not work for "Pull Up" due to the > built in LED and resistor. There should also be a short explanation about > PullUp resistors for beginners. > > - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a > lot of time at the beginning making lots of complicated cable connections > because the help patch recommends connecting the pins to ground instead of > simply switching on the PullUp resistors. At least as long as you are not > at > the very limit of your power supply. > > Since I only use the digital and analogue ins I didn't look any further. > So > I can't say anything about the output stuff. > > The digital pins 2 & 3 should really be fixed sometime soon. I was hoping > you'd be getting some of these problems solved rather than putting a grey > background to the help patch (lol). > > Ingo > > > > Hi Ingo > > > > On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: > > > OK, I got it! > > > > > > Downloading the files didn't work (at least not on my Windows > computer) > > but > > > copying the content into a bunch of text files and renaming them did. > > > > Hm.. is this probably due to Windows and Linux using different line > > breaks (\r\n vs. \n)? > > > > > I'll take a look at it later to see if the problems with the 1st and > 2nd > > > digital input as well as my problems with inputs 10 - 13 are gone. > > > > FYI: We haven't tinkered with the protocol. At this stage it's really > > only a version with some externals kicked out. > > Anyway, please report back, if you still experience the same problems. > > > > Are you testing on a Arduino Mega? > > > > Roman > > > ___ > 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] pduino rewrite
Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 & 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as "PullDown". It's only "PullUp". It should be mentioned that pin 13 does not work for "Pull Up" due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 & 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Ingo > Hi Ingo > > On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: > > OK, I got it! > > > > Downloading the files didn't work (at least not on my Windows computer) > but > > copying the content into a bunch of text files and renaming them did. > > Hm.. is this probably due to Windows and Linux using different line > breaks (\r\n vs. \n)? > > > I'll take a look at it later to see if the problems with the 1st and 2nd > > digital input as well as my problems with inputs 10 - 13 are gone. > > FYI: We haven't tinkered with the protocol. At this stage it's really > only a version with some externals kicked out. > Anyway, please report back, if you still experience the same problems. > > Are you testing on a Arduino Mega? > > Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. Ingo > Betreff: Re: [PD] pduino rewrite > > I could not open any patch at all! Neither Natty nor Windows XP worked. > I am still on Pd-extended 0.42.5. > There is a huge list of stuff (not pd library related) missing. > > So far this doesn't look like it's improving any dependency problem. > > Ingo > > > > buenas tutti > > > > roman & me did some rewrite on the pduino - citing the README: > > > > Pduino - improved > > - > > > > All Pd patches are based on the official Pduino (version 0.5beta8) > > maintained by Hans-Christoph Steiner. > > > > > > The goals of the improvements are: > > > >* Get rid of avoidable dependencies on other external/abstraction > > libraries > > > >* Update help- and test-patches in accordance to current Firmata > > > >* Create 'intuitive' and easy-to-understand GOP abstraction > > > > > > Dependencies: > > > >* comport > > > >* pdstring library from moocow > > > > you'll find the patches here: > > https://github.com/reduzent/pduino > > > > the GOP-abstraction is still in tango alpha state aka not useable at > all. > > so basically arduino.pd & arduino-help.pd should be of interest. as they > > went thru some changes - most important the > > dependencies are reduce to the minimum. > > check it out & report > > > ___ > 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] pduino rewrite
I could not open any patch at all! Neither Natty nor Windows XP worked. I am still on Pd-extended 0.42.5. There is a huge list of stuff (not pd library related) missing. So far this doesn't look like it's improving any dependency problem. Ingo > buenas tutti > > roman & me did some rewrite on the pduino - citing the README: > > Pduino - improved > - > > All Pd patches are based on the official Pduino (version 0.5beta8) > maintained by Hans-Christoph Steiner. > > > The goals of the improvements are: > >* Get rid of avoidable dependencies on other external/abstraction > libraries > >* Update help- and test-patches in accordance to current Firmata > >* Create 'intuitive' and easy-to-understand GOP abstraction > > > Dependencies: > >* comport > >* pdstring library from moocow > > you'll find the patches here: > https://github.com/reduzent/pduino > > the GOP-abstraction is still in tango alpha state aka not useable at all. > so basically arduino.pd & arduino-help.pd should be of interest. as they > went thru some changes - most important the > dependencies are reduce to the minimum. > check it out & report ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] selecting an alsa soundcard at startup
That's what I was thinking, too. But it doesn't work like this. The devices I create with udev show up in /dev. But the devices used by /etc/modprobe.d/alsa-base.conf : snd-emu10k1 snd_intel8x0 do not show up in /dev. That means the sound device names are created somewhere else. Names that I create with udev in /dev seem to be ignored by modprobe.d/alsa-base.conf. So the question is where are these sound card IDs generated and how could I create such an ID with udev? Ingo >>On Sun, Sep 4, 2011 at 14:33, Ingo wrote: >>Has anybody had any success with udev? >> >>I need to use oss and have tried to create a udev.rule to connect two >>identical usb midi interfaces and identify them by the usb port. >> >>I ended up creating the devices in /dev/ and /dev/snd/ and named them >>/dev/midi1, /dev/midi2 and/or /dev/snd/midiC1D0, /dev/snd/C2D0. >> >>They show up correctly in the folder /dev/ but I don't know how to assign >>them to anything alsa-base.conf can use. >> >>The first one that gets plugged in is always midi1 no matter where I plug it >>in. If I plug only one of them into the second usb port it will create >>midi1 and midi2. alsa-base.conf cannot seem to use the udev rules. >>It looks like something is assigning the soundcard numbers before or after >>udev. >> >>Any ideas? >> >>Ingo >More than udev it might be a modprobe thing. >I have these rules in /etc/modprobe.d/alsa-base.conf : > >options snd-emu10k1 index=0 >options snd_intel8x0 index=1 > >...which make my Soundblaster card always be hw:0 and the motherboard sound >card be hw:1. > >Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
