Re: [PD] Chicago Patching Circle (Sunday, December 14th)
I could still meet informally on the 18th.
I'd also like to recommend a meet up location different than a bar, at least
for future meetings.
Rumble Arts Center, in Humbolt Park, offers affordable meeting space. I
spoke with the person in charge and she said she usually they charge $50 to
rent a meeting space, but that it was negotiable. They offer a lot of
community-based classes, so maybe even some sort of Pd workshop could become
part of their offerings, and we could get in on that.
I'm going to set up a more formal time to talk with her, so if I could get a
vague notion of how many people we could get in February as well as a more
concrete date and time, I could hammer something out.
~Kyle
On Sun, Jan 11, 2009 at 1:16 AM, Jacob Lee artd...@gmail.com wrote:
Why don't we meet informally on the 18th? We could just demonstrate
patches and whatnot and save a more formal show for February. I, too,
have less to show by now than I had hoped, but I'd still like to get
together and see what else people are doing in PD.
--
Jacob Lee
artd...@gmail.com
On Fri, Jan 9, 2009 at 6:25 PM, Mike McGonagle mjm...@gmail.com wrote:
Well, my vote would be for February, as the stuff I have been working
on is kind of slow going... plus it just seems that the 18th is a bit
closer than I had anticipated. Maybe we should set a date NOW in
February, and then make plans for that...
But, if others would still like to shoot for the 18th, I don't think
it would be a problem to hold it at the Red Line Tap. It would have to
be before 6PM, as they have been scheduling bands on Sunday nights,
and they usually start setting up around 8 or so...
Mike
On Fri, Jan 9, 2009 at 5:54 PM, Kyle Klipowicz kylek...@gmail.com
wrote:
Hey Chi-town Pd-ers~
This may be a little late, but I can do the 18th of January.
Is this going to happen still, or should we push it back to February to
get
a little promotion time?
Let's decide soon.
~Kyle
On Sun, Dec 28, 2008 at 3:35 PM, Mike McGonagle mjm...@gmail.com
wrote:
Well, any suggestions would be welcome. While I am not quite certain,
I am pretty sure that we can still meet at the Red Line Tap, they just
want to get a few more bodies in to buy a beer or two for the time we
are there...
The 18th is the third sunday... does that sound like a good day?
Anyone have another date in mind?
Mike
On Sun, Dec 28, 2008 at 2:24 PM, Kyle Klipowicz kylek...@gmail.com
wrote:
So...Any word on a mid-January date for the Pd meetup in Chicago yet?
~Kyle
On Sun, Dec 14, 2008 at 12:46 PM, Mike McGonagle mjm...@gmail.com
wrote:
Yes, the safe money is on that... no meeting tonight...
Our latest plan is to shoot for mid January...
Mike
On Sun, Dec 14, 2008 at 12:38 PM, Anthony Curry
theonlyconstantisf...@gmail.com wrote:
Hey all,
Hope this message finds you all happy and well.
Is it safe to assume that we're NOT meeting at the Red Line Tap
this
evening?
Thanks,
Anthony
theonlyconstantisf...@gmail.com
--
Peace may sound simple—one beautiful word— but it requires
everything
we have, every quality, every strength, every dream, every high
ideal.
—Yehudi Menuhin (1916–1999), musician
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
--
Peace may sound simple—one beautiful word— but it requires everything
we have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
--
Peace may sound simple—one beautiful word— but it requires everything
we have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] converting from midi to frequency in just intonation
Hallo, Amos Robinson hat gesagt: // Amos Robinson wrote: I was curious to play with just intonation earlier but couldn't find any easy way to calculate an frequency based on a midi note. (It's entirely possible that I just didn't look hard enough, though) So, here's a really simple and ugly cludge just in case. There must be a better way to do this, but I don't know it. I couldn't look at your patch, but maybe you also like [tunetof] from the SVN in the directory /abstractions/footils/tunetof/ It's like [mtof] but converts scale steps according to tunings made with Scala. The Scala files have to be converted using a Python script included in the tunetof distribution. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote: i have a question regarding timing in Pd: I understand that messages to tilde objects just get passed to the DSP tree within DSP blocks. How about the reverse? Found out that snapshot~ is returning the last sample of the last block during which it got banged. This is fine, since it is the sample value most closely to the output of the result. Now when i use the following setup: [bang~] | | [t b b] | | | | [timer] i get a minimum logical time of 1.45 msec (aquivalent to 64samples at 44.1 kHz) even when i use a blocksize of [block~ 32]. I think, bang~ should bang after each block, so with [block~ 32] it should bang every 32 samples. But it seems to have a lower limit of 64 samples. Don't know why. In general, Pd has like to times: One is the time realm of clock-delayed messages, i.e. everything that originates in a clock objects like metro, delay, pipe, qlist, etc. Clock delayed messages have sub-sample accuracy. This is achieved by tagging each normal message with a time tag, similar to the old time tagged triggers in t3_lib. The tags for clocks are invisible, though. To convert dsp signals to clock-delayed messages you must use [vsnapshot~], but [snapshot~]. It will give you the value of a sample even when bang'ed somewhere in the middle of a block. Note that you cannot use this value to modify other samples during the same block! Because when the message comes out of [vsnapshot~], this block has already been calculated. So you can only start to use the value to modify the next block's content. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd in hongkong?
hi list i'm going to hongkong and wondered if there are any pd user around. please drop me a line if you want to meet before new year :) cheers eni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Hi all, Frank Barknecht wrote: Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote: i have a question regarding timing in Pd: I understand that messages to tilde objects just get passed to the DSP tree within DSP blocks. How about the reverse? Found out that snapshot~ is returning the last sample of the last block during which it got banged. This is fine, since it is the sample value most closely to the output of the result. Now when i use the following setup: [bang~] | | [t b b] | | | | [timer] i get a minimum logical time of 1.45 msec (aquivalent to 64samples at 44.1 kHz) even when i use a blocksize of [block~ 32]. I think, bang~ should bang after each block, so with [block~ 32] it should bang every 32 samples. But it seems to have a lower limit of 64 samples. Don't know why. thanks for the reply, Frank. That's what made me curious. Since the duration of a DSP-block does not belong to the realm of clock-delayed messages (pd can't know of the exact duration of the DSP block, assume f.e. an external audio clock with jitter) those values may have to be sampled by the messaging system. This sampling would then appear at a minimum rate of 64 samps. So bang~ only makes sense for blocksizes greater than 32 samples, right? Phew, does that make sense? Still trying to completely understand that. In general, Pd has like to times: One is the time realm of clock-delayed messages, i.e. everything that originates in a clock objects like metro, delay, pipe, qlist, etc. Clock delayed messages have sub-sample accuracy. This is achieved by tagging each normal message with a time tag, similar to the old time tagged triggers in t3_lib. The tags for clocks are invisible, though. Timing is a very interesting topic in pd (and with computers in general). When i try to measure the [realtime] of a [metro 4] object, i get: print: 11.351 print: 0.122 print: 0.11 print: 11.402 print: 0.088 print: 0.119 print: 11.374 I think you get the same values. Can it be true that there is a deviation of 7ms now and then? More interesting: Why is it not only now-and-then, but every fourth sample? So there must be some phase shift which accumulates in the operation of [realtime]. On averaging those values, one gets a value close to 4ms though. Does anyone know about the real-life resolution of [realtime]? cheers, Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
On Sun, 2009-01-11 at 12:26 +0100, Peter Plessas wrote: Timing is a very interesting topic in pd (and with computers in general). When i try to measure the [realtime] of a [metro 4] object, i get: print: 11.351 print: 0.122 print: 0.11 print: 11.402 print: 0.088 print: 0.119 print: 11.374 I think you get the same values. Can it be true that there is a deviation of 7ms now and then? More interesting: Why is it not only now-and-then, but every fourth sample? So there must be some phase shift which accumulates in the operation of [realtime]. On averaging those values, one gets a value close to 4ms though. Does anyone know about the real-life resolution of [realtime]? those time steps seem to be related to the audio driver. you seem to run pd on jack with a latency of 23ms / 512 frames per buffer @ 44.1kHz. when i use 2048 per buffer at 44.1kHz, i get 92 ms latency and the numbers look like this: print: 0.048 print: 0.047 print: 0.033 print: 0.049 print: 0.05 print: 45.916 print: 0.04 print: 0.05 print: 0.051 print: 0.052 print: 0.035 print: 0.05 print: 0.064 print: 0.052 print: 0.032 print: 0.046 print: 0.048 print: 45.825 print: 0.033 print: 0.047 so, here every 12th number is significantly bigger than 0 and also here, this number is approximately the half of the latency. this behaviour seems to be typical for jack. when i run pd in windows in virtualbox, i get more random looking numbers. i guess, if you want really accurate realtime values, you would have to go for the least possible latency, since it seems, that time of execution of pd is completely dependent on the audio driver. and even if this would cause drop-outs, the results of [realtime] wouldn't be affected in a way, that the overall measured time is still valid. if you use [timer], which measures logical time, and you get drop-outs, all dropped out time is not part of the measurement and you will get wrong (too small) values as a result. i never understood, why [timer] is giving different values from the ones that you expected, when connected to a [bang~] inside a re-blocked subpatch. would be cool to have that either explained or declared as a bug. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Thanks Roman, (see for comments below) Roman Haefeli wrote: On Sun, 2009-01-11 at 12:26 +0100, Peter Plessas wrote: Timing is a very interesting topic in pd (and with computers in general). When i try to measure the [realtime] of a [metro 4] object, i get: print: 11.351 print: 0.122 print: 0.11 print: 11.402 print: 0.088 print: 0.119 print: 11.374 I think you get the same values. Can it be true that there is a deviation of 7ms now and then? More interesting: Why is it not only now-and-then, but every fourth sample? So there must be some phase shift which accumulates in the operation of [realtime]. On averaging those values, one gets a value close to 4ms though. Does anyone know about the real-life resolution of [realtime]? those time steps seem to be related to the audio driver. you seem to run pd on jack with a latency of 23ms / 512 frames per buffer @ 44.1kHz. when i use 2048 per buffer at 44.1kHz, i get 92 ms latency and the numbers look like this: I did this test with -audiobuf 50 running OSS. You are right, the values differ greatly on the kind of audio driver i am using, f.e. with alsa and -audiobuf 50 i get: print: 0.1 print: 4.928 print: 4.991 print: 4.951 print: 4.994 print: 0.098 print: 4.931 print: 4.994 print: 4.949 while using alsa and -audiobuf 100 the result is slightly different as well. And all this while DSP processing is even turned off. i guess, if you want really accurate realtime values, you would have to go for the least possible latency, since it seems, that time of execution of pd is completely dependent on the audio driver. and even if this would cause drop-outs, the results of [realtime] wouldn't be affected in a way, that the overall measured time is still valid. if you use [timer], which measures logical time, and you get drop-outs, all dropped out time is not part of the measurement and you will get wrong (too small) values as a result. So realtime is dependent on the audio clock? I always thought that it took the cputime/OS time... I understand that logical time in timer is the internal perfect representation of pd's time. i never understood, why [timer] is giving different values from the ones that you expected, when connected to a [bang~] inside a re-blocked subpatch. would be cool to have that either explained or declared as a bug. Yes, that one is still unclear to me. regards, Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Hiding bits of the subpatch
On Sat, Jan 10, 2009 at 09:32:32PM -0600, Mike McGonagle wrote: One thing I noticed is that when you click to open and close these gadgets, it will leave the patch in a dirty state, and it will ask you if you want to save the patch before closing it. Yeah, that sucks for sure, I forgot all about that. Would be great if it was possible to send a message 'clean' to a patch to undo the dirty flag. Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Hi again, Frank(ly), there is still something unclear to me. Please see below. Frank Barknecht wrote: In general, Pd has like to times: One is the time realm of clock-delayed messages, i.e. everything that originates in a clock objects like metro, delay, pipe, qlist, etc. Clock delayed messages have sub-sample accuracy. This is achieved by tagging each normal message with a time tag, similar to the old time tagged triggers in t3_lib. The tags for clocks are invisible, though. I understand you mean Pd has two times, the first one being the sub-samply accuracy of clock-delayed objects like [delay]. (I exclude metro from this group since it has the hard-coded limit of integer msec values). What would be the other timing then? Thanks! have a nice one, PP ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
On Sun, 2009-01-11 at 14:05 +0100, Peter Plessas wrote: Hi again, Frank(ly), there is still something unclear to me. Please see below. Frank Barknecht wrote: In general, Pd has like to times: One is the time realm of clock-delayed messages, i.e. everything that originates in a clock objects like metro, delay, pipe, qlist, etc. Clock delayed messages have sub-sample accuracy. This is achieved by tagging each normal message with a time tag, similar to the old time tagged triggers in t3_lib. The tags for clocks are invisible, though. I understand you mean Pd has two times, the first one being the sub-samply accuracy of clock-delayed objects like [delay]. (I exclude metro from this group since it has the hard-coded limit of integer msec values). this is not true. [metro] also works with non-integer time intervals, though it has a hardcoded lower limit of 1ms (i guess, that is some kind of stack overflow protection). What would be the other timing then? while not being 100% sure, what frank meant with the other timing domain, i guess, he meant all the messages, that are not initiated by [metro]/[delay]/[pipe] and co. this would be messages from: - the guis and clicks on message boxes - networking objects [netreceive]/[tcpreceive] etc. - [hid] / [comport] / [arduino] / [wiimote] - [cltin] / [notein] / [midiin] etc. - probably more all those messages lack the extra timing information and thus are executed only at block boundaries. for the same reasons explained in the previous mail about [realtime], all those object classes seem to suffer from a big (bigger than 1 block) and audio driver/settings dependent jitter as well. you don't exactly know, when those messages arrive in pd. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Thanks for the discussion Roman, see below Roman Haefeli wrote: while not being 100% sure, what frank meant with the other timing domain, i guess, he meant all the messages, that are not initiated by [metro]/[delay]/[pipe] and co. this would be messages from: - the guis and clicks on message boxes - networking objects [netreceive]/[tcpreceive] etc. - [hid] / [comport] / [arduino] / [wiimote] - [cltin] / [notein] / [midiin] etc. - probably more all those messages lack the extra timing information and thus are executed only at block boundaries. I managed to find something that contradicts here: A Gui-bang to a [t b b] to a [timer] in a subpatch with a [block~ 8192] object. Clicking the bang very fast with my mouse gives smaller than blocksize message intervals: print: 127.71 print: 116.1 print: 116.1 print: 127.71 print: 116.1 print: 127.71 print: 104.49 print: 92.8798 print: 104.49 print: 81.2698 print: 104.49 print: 116.1 usw. Hmmm, still searching. Thanks for all the good pointers! regards, PP ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Peter Plessas wrote: Thanks for the discussion Roman, see below Roman Haefeli wrote: while not being 100% sure, what frank meant with the other timing domain, i guess, he meant all the messages, that are not initiated by [metro]/[delay]/[pipe] and co. this would be messages from: - the guis and clicks on message boxes - networking objects [netreceive]/[tcpreceive] etc. - [hid] / [comport] / [arduino] / [wiimote] - [cltin] / [notein] / [midiin] etc. - probably more all those messages lack the extra timing information and thus are executed only at block boundaries. That's the adc~/dac~ block boundaries, so... I managed to find something that contradicts here: A Gui-bang to a [t b b] to a [timer] in a subpatch with a [block~ 8192] ...that's why. object. Clicking the bang very fast with my mouse gives smaller than blocksize message intervals: print: 127.71 print: 116.1 print: 116.1 print: 127.71 print: 116.1 print: 127.71 print: 104.49 print: 92.8798 print: 104.49 print: 81.2698 print: 104.49 print: 116.1 note the quantisation! 127.7 ms = 88 blocks exactly 116.1 ms = 80 blocks exactly 104.5 ms = 72 blocks exactly 92.88 ms = 64 blocks exactly at 44100Hz with 64 samples per block so i'm guessing your audio driver has a block size of 512 samples (8 * 64), which Pd fills with its 64 sample blocks quicker than you can click twice = massive jitter of logical time vs real time. usw. Hmmm, still searching. Thanks for all the good pointers! regards, PP ___ 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] oggcast~ and similar objects - noobie question
Hello, I recently installed pd-extended on my OSX 10.5 mac and i am trying to setup a patch using the oggcast~, oggamp~, etc. externals and it says that I don't have them. tried /Applications/pd/Pd-extended.app/Contents/Resources/extra/oggcast~.pat and failed oggcast~ 1 512 ... couldn't create I thought they were part of the pd-extended install? It is listed on the pd site. Is there anything else I need to do or download to have the externals work? Thanks, Carey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Claude Heiland-Allen wrote: Peter Plessas wrote: Thanks for the discussion Roman, see below Roman Haefeli wrote: while not being 100% sure, what frank meant with the other timing domain, i guess, he meant all the messages, that are not initiated by [metro]/[delay]/[pipe] and co. this would be messages from: - the guis and clicks on message boxes - networking objects [netreceive]/[tcpreceive] etc. - [hid] / [comport] / [arduino] / [wiimote] - [cltin] / [notein] / [midiin] etc. - probably more all those messages lack the extra timing information and thus are executed only at block boundaries. That's the adc~/dac~ block boundaries, so... Wow Claude, that explains it. Wonderful indeed. So the logical timing of externally triggered objects, those who don't show a predetermined behavior like a [del 0.3] is dependent on the adc/dac block boundaries. Thanks for calculating the [timer] output into multiples of eight blocks for me! cheers, Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote: That's what made me curious. Since the duration of a DSP-block does not belong to the realm of clock-delayed messages Actually it does belong to the same realm AFAIK: Pd's clock is computed using the audio card as a reference. Subsample accuracy just means, that events can be scheduled between samples as well. But the time, when they should be scheduled, is still calculated from the audio card. In the end [metro] will have the same jitter as the audio card. Maybe an example makes this clearer: Lets assume you have a digital watch that only shows hours and minutes, but no seconds. So it has a sample rate of 1/60 Hz. Now you want to boil an egg for breakfast. You like your eggs if they have been boiled for three and a half minutes. So you drop your egg into the water when the watch is changing minutes. After three minutes you start interpolating: You have to take the egg out of the water halfway in between the ticks that come every minute. (If your watch has a lot of jitter, you egg will be wrong, too.) That's the same sub-sample accuracy Pd uses to schedule events that should happpen in the middle of a block or between two samples. For the nasty details check out Miller's book http://crca.ucsd.edu/~msp/techniques/latest/book-html/node43.html where he explains the various possible techniques to use for interpolating between two ticks. Also see http://crca.ucsd.edu/~msp/techniques/latest/book-html/node52.html for how it's implemented in Pd and everything else in that chapter, too. (pd can't know of the exact duration of the DSP block, assume f.e. an external audio clock with jitter) those values may have to be sampled by the messaging system. This sampling would then appear at a minimum rate of 64 samps. So bang~ only makes sense for blocksizes greater than 32 samples, right? Phew, does that make sense? Still trying to completely understand that. I don't understand what this has to do with [bang~]? Does anyone know about the real-life resolution of [realtime]? I think this depends on how accurate your operation systems realtime clock is. On Linux, you can maybe check: /proc/sys/dev/hpet/max-user-freq rsp. /proc/sys/dev/rtc/max-user-freq for the max allowed polling frequency or so. But I'm no expert on this. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Dear Roman, Frank, List Roman Haefeli wrote: while not being 100% sure, what frank meant with the other timing domain, i guess, he meant all the messages, that are not initiated by [metro]/[delay]/[pipe] and co. this would be messages from: - the guis and clicks on message boxes - networking objects [netreceive]/[tcpreceive] etc. - [hid] / [comport] / [arduino] / [wiimote] - [cltin] / [notein] / [midiin] etc. - probably more all those messages lack the extra timing information and thus are executed only at block boundaries. I'm just interested, how would you argue that the logical timing of the following is sub-adc/dac-block (which it is)? [t b b] |\ | \ | \ | \ [t b b] [random 100] || | [/ 100] | / | / | / [delay] | [t b b] | | [timer] | [print] Clearly we all agree that [del] follows Pd's time tagged execution. So this time tag must be set with respect to the whole logical tree, including the new value given by the [random] object, right? cheers, Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote: I understand you mean Pd has two times, the first one being the sub-samply accuracy of clock-delayed objects like [delay]. (I exclude metro from this group since it has the hard-coded limit of integer msec values). [metro] has a hardcoded lower limit, but it is not limited to integer values, it works fine with real floats like 133. What would be the other timing then? The other are messages that don't originate in a clock (and still another kind are messages from the outside world.) Clicking on a GUI object for example does not generate a clock-delayed message. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] oggcast~ and similar objects - noobie question
On Sun, 2009-01-11 at 12:23 -0500, carey dodge wrote: Hello, I recently installed pd-extended on my OSX 10.5 mac and i am trying to setup a patch using the oggcast~, oggamp~, etc. externals and it says that I don't have them. try: [pdogg/oggcast~] and [pdogg/oggamp~] roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] oggcast~ and similar objects - noobie question
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sun, 2009-01-11 at 12:23 -0500, carey dodge wrote: Hello, I recently installed pd-extended on my OSX 10.5 mac and i am trying to setup a patch using the oggcast~, oggamp~, etc. externals and it says that I don't have them. try: [pdogg/oggcast~] and [pdogg/oggamp~] Or [import pdogg] [oggcast~] [oggamp~] Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
On Sun, 2009-01-11 at 18:34 +, Florian Hollerweger wrote: i never understood, why [timer] is giving different values from the ones that you expected, when connected to a [bang~] inside a re-blocked subpatch. would be cool to have that either explained or declared as a bug. Sorry, Roman - could you clarify which blocksizes you are talking about? What Peter and I have observed is that block sizes 64 give the same [timer] results as a block size of 64, so there seems to be a lower limit. I am not sure though whether you are you talking about the same phenomenon? yo, this is what i was talking about. in a subpatch with a lower blocksize than 64, [bang~] still outputs a bang only every 64 samples. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
Hi Peter/Roman/Frank, hi list, Thanks for the lively discussion and your insightful contributions. Peter Plessas wrote: So realtime is dependent on the audio clock? I always thought that it took the cputime/OS time... [realtime] takes the system time as measured by the OS. (For clarity, I would not call it CPU time, since that is the amount of time a computer program uses in processing central processing unit (CPU) instructions, as opposed for example to waiting for input/output operations (Wikipedia), as measured by [cputime] in Pd in order to derive the current CPU load in Pd's load meter, for example.) For example, when you reset the clock using the Unix 'date' command during an ongoing [realtime] measurement, that change will affect the measurement's result. So in my understanding, [realtime] does _not_ depend on the audio clock (or audio driver); it gives accurate values also for measurements of [metro 2], etc. It's the actual timing of [metro] which gets messed up. Or am I getting your question wrong here? I understand that logical time in timer is the internal perfect representation of pd's time. That's my understanding as well. [timer] represents the ideal score derived from all timed objects ([del], [metro], etc.). It's what Pd 'aims for'. i never understood, why [timer] is giving different values from the ones that you expected, when connected to a [bang~] inside a re-blocked subpatch. would be cool to have that either explained or declared as a bug. Sorry, Roman - could you clarify which blocksizes you are talking about? What Peter and I have observed is that block sizes 64 give the same [timer] results as a block size of 64, so there seems to be a lower limit. I am not sure though whether you are you talking about the same phenomenon? best, flo.H ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Hiding bits of the subpatch
Well, I don't know exactly what is causing this to happen, but one other thing that does this is if you have a patch open, and just hitting one of the cursor keys will also cause a patch to become dirty. Maybe there is some relationship there... Mike On Sun, Jan 11, 2009 at 7:01 AM, Chris McCormick ch...@mccormick.cx wrote: On Sat, Jan 10, 2009 at 09:32:32PM -0600, Mike McGonagle wrote: One thing I noticed is that when you click to open and close these gadgets, it will leave the patch in a dirty state, and it will ask you if you want to save the patch before closing it. Yeah, that sucks for sure, I forgot all about that. Would be great if it was possible to send a message 'clean' to a patch to undo the dirty flag. Chris. --- http://mccormick.cx -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FUDI protocol specifications
Fear-Uncertainty-Doubt-Interface. I guess M$'s FUD has stuck with me... .hc On Jan 10, 2009, at 7:50 PM, Miller Puckette wrote: 'Fast Unified Digital Interface' (or whatever other acronym people can come up with :) M On Sun, Jan 11, 2009 at 01:44:35AM +0100, Roman Haefeli wrote: hi all FUDI was subject of a little discussion on #dataflow, so we tried to put everything we could find togehter to a pdpedia page. however, all the information was gained from some tests with [netreceive], but we couldn't find any official specification nor what the acronym stands for. is the information on [1] correct? what does FUDI mean? roman [1] http://wiki.puredata.info/en/FUDI ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ 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 If you are not part of the solution, you are part of the problem. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] logical timing question
i get a minimum logical time of 1.45 msec (aquivalent to 64samples at 44.1 kHz) even when i use a blocksize of [block~ 32]. I think, bang~ should bang after each block, so with [block~ 32] it should bang every 32 samples. But it seems to have a lower limit of 64 samples. Don't know why. iirc, bang~ uses pd's timer callbacks, which are only executed once every dsp tick, i.e. each 64 samples. while pd has a notion of `logical time', timers for the interval of 64 samples are executed at the same time. if the same timer callback is scheduled twice during this interval, it is only executed once ... tim -- t...@klingt.org http://tim.klingt.org Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd-extended 0.41.4 nightlies now available
Starting today, there are now some Pd-extended 0.41.4 nightly builds available: http://autobuild.puredata.info/auto-build/2009-01-11/ Start testing them so we can get the release out quickly! .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] converting from midi to frequency in just intonation
Oh, that's beautiful; all my dreams come true! I'll have to play with it very soon. On Sun, Jan 11, 2009 at 8:51 PM, Frank Barknecht f...@footils.org wrote: Hallo, Amos Robinson hat gesagt: // Amos Robinson wrote: I was curious to play with just intonation earlier but couldn't find any easy way to calculate an frequency based on a midi note. (It's entirely possible that I just didn't look hard enough, though) So, here's a really simple and ugly cludge just in case. There must be a better way to do this, but I don't know it. I couldn't look at your patch, but maybe you also like [tunetof] from the SVN in the directory /abstractions/footils/tunetof/ It's like [mtof] but converts scale steps according to tunings made with Scala. The Scala files have to be converted using a Python script included in the tunetof distribution. Ciao -- Frank ___ 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
