Re: [PD] flatspace externals in ext39.2
On 5 May 2007, at 5:14 AM, Hans-Christoph Steiner wrote: [classpath] == [declare -stdpath] Adds a path to the global search path. thats great! - I wasn't aware of [classpath] -- now I can stop wrangling preferences/users trying to get different paths and libraries for different versions. a few questions not explained in the helpfiles: - is there a way to use relative pathnames? - and if so what are they relative to? - is it possible to refer to the users home folder? - what version of pd do they require (they seem to create ok in millers OSX 0.40 and 0.39) - when can I use the libdir system to load a directory of externals? I hope there are plans for inclusion in the miller pd distribution soon (though a least it is fairly easy to explain how to add them, even to a novice user). thanks for getting this working, simon ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] New to PD on Mac OSX-Output makes
On 6 May 2007, at 7:11 PM, Tuomas Brock wrote: spits out these rythmic blips. So it goes blip..blip..blip etc etc etc search the archives of this list http://lists.puredata.info/pipermail/ pd-list/ this exact problem, and a solution, has come up several times (but I have never experienced the problem and I've used many new and old Macs). Using JackOSX as the audio interface has lots of advantages in OSX (and is said to be more stable in Pd), I always use it. Download from http://www.jackosx.com/. simon ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] flatspace externals in ext39.2
simon wise wrote: On 5 May 2007, at 5:14 AM, Hans-Christoph Steiner wrote: [classpath] == [declare -stdpath] Adds a path to the global search path. thats great! - I wasn't aware of [classpath] -- now I can stop wrangling preferences/users trying to get different paths and libraries for different versions. I hope there are plans for inclusion in the miller pd distribution soon (though a least it is fairly easy to explain how to add them, even to a novice user). hmm, i don't fully understand your request: hans just told you that [classpath] (an external) is basically the same as [decalre -stdpath] (which comes with pd-vanilla) so why don't you just use [declare]? apart from the fact, that [declare] has a slightly more complicated syntax and merges more or less independent functionality, it also has some advantages: e.g. it is treated specially by pd (it always gets saved as the very first part of the patch, no matter when you actually put the object there; i don't think (but otoh i don't know) that [classpath] can offer you the same) mfg.a sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] flatspace externals in ext39.2
On 7 May 2007, at 5:08 PM, IOhannes m zmoelnig wrote: so why don't you just use [declare]? apart from the fact, that [declare] has a slightly more complicated syntax and merges more or less independent functionality, it also has some advantages: e.g. it is treated specially by pd (it always gets saved as the very first part of the patch, no matter when you actually put the object there thanks - how to ensure it was 'first' was the next thing I was trying to find out, I'll certainly use [declare], I wasn't aware of what it did - its relative path choices are exactly what I need. It is new to 0.40? simon ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: [SOSCroute] is a settable OSCroute (for Frank)
Aha! So it does : ). Ah well, I enjoyed myself. Luke On 5/6/07, Jamie Bullock [EMAIL PROTECTED] wrote: Hi Luke, On Fri, 2007-05-04 at 23:27 -0700, Luke Iannini (pd) wrote: Hallo all, Here is a dynamically generated OSCroute that lets its route argument be reset by a right inlet. Nice work! But isn't this problem already solved by the [routeOSC] external by Martin Peach (available in the CVS)? Jamie ___ 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] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
On Mon, 2007-05-07 at 09:40 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. wow, great news again how did you find out about this? it is not mentioned in the release notes. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... oh, hm... indeed, strange. 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] flatspace externals in ext39.2
Hallo, simon wise hat gesagt: // simon wise wrote: I hope there are plans for inclusion in the miller pd distribution soon (though a least it is fairly easy to explain how to add them, even to a novice user). [classpath] is GPL, so unless Miller plans to switch Pd to GPL (which I doubt) it may only be shipped as an external like [expr]. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not working as expected, though it definitely gives other results than [snapshot~]. one issue might be introduced by the rounding error of floats. the other i cannot explain. vsnapshot~ seems to pick sometimes the wrong value. roman On Mon, 2007-05-07 at 09:40 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... Ciao #N canvas 546 0 366 477 10; #X floatatom 12 131 0 0 0 0 - - -; #X obj 12 109 vsnapshot~; #X msg 13 53 10; #X obj 69 79 metro 100; #X msg 69 56 1; #X obj 13 76 phasor~; #X obj 13 20 loadbang; #X floatatom 12 319 0 0 0 0 - - -; #X obj 12 297 vsnapshot~; #X obj 13 264 phasor~; #X obj 13 208 loadbang; #X msg 13 241 50; #X obj 69 267 metro 20; #X msg 69 244 1; #X obj 12 348 t f f; #X text 7 178 is this the rounding error of floats?; #X obj 11 373 -; #X floatatom 11 397 0 0 0 0 - - -; #X text 10 424 why this discontuinities?; #X text 9 158 phasor (10Hz) and metro (100ms) do drift apart.; #X connect 1 0 0 0; #X connect 2 0 5 0; #X connect 3 0 1 0; #X connect 4 0 3 0; #X connect 5 0 1 0; #X connect 6 0 2 0; #X connect 6 0 4 0; #X connect 7 0 14 0; #X connect 8 0 7 0; #X connect 9 0 8 0; #X connect 10 0 11 0; #X connect 10 0 13 0; #X connect 11 0 9 0; #X connect 12 0 8 0; #X connect 13 0 12 0; #X connect 14 0 16 1; #X connect 14 1 16 0; #X connect 16 0 17 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: wow, great news again how did you find out about this? it is not mentioned in the release notes. Use the source, Luke: I was considereing to code my own vsnapshot~ and looked into d_ctl.c where I found, that Miller already did it. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Exquisite corpse
my friends and i have done a few mixes liek this and the ended up great. of course i'm in. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_set in RGB mode
Nicolas Montgermont wrote: Hi list, I try to control the color of pixels using [pix_set], the object works well but there is a behavior that I want to change: when you set the color of a pixel, it is calculating a kind of interpolation with the neighbours, is it possible to plot it like a simple square, without any interpolation? send [quality 0( to [pix_texture] mfg.asdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sending data from PD to another program
Hallo, David Powers hat gesagt: // David Powers wrote: Here you go, just use the tree abstraction and create named nodes for every event in your story! Note that the nodes are hard coded to send to master, you'd want another master receiver for your GEM abstraction to select the image which goes with the current node. Oh, and of course replace the PD selector patch, which sends random 0 or 1, with your actual voting mechanism. ~David On 5/6/07, David Powers [EMAIL PROTECTED] wrote: I think I will try to do a quick prototype and email it to you in 15-20 minutes. ~David On 5/6/07, Jared [EMAIL PROTECTED] wrote: David, Thanks for the reply. That's basically what I want to do. My concern is that there are around 80 nodes which have to be displayed in specific if-then sequences (if it's at node 12 and the vote is A, go to node 33, if the vote is B go to node 37). My understanding of PD means this isn't *impossible*, it'll just be a bit clunky. If you have any suggestions to the contrary, I'd love to hear 'em. I attached another solution to your problem, which may be easier to extend to 80 nodes, because not much patching is involved, instead you write a textfile with a definition of your state transitions (because basically what you seem to long for is just that: a state machine). The idea is to write a textfile where every line represents a certain state of your system indicated by the line number. The content of a line then specifies the possible transitions. In the example patch every state has two possible follow-up states written as numbers. Depending on the choice of a user (0 or 1 in the example) a new state is selected by selecting either the first or the second follow-up state and making that the new active state. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ state-machine.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Roman Haefeli wrote: i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not working as expected, though it definitely gives other results than [snapshot~]. i think it is working as expected but there are 2 things to bear in mind: one issue might be introduced by the rounding error of floats. the other i cannot explain. vsnapshot~ seems to pick sometimes the wrong value. [vline~] and [vsnapshot~] do not work exactly alike, because of this vexed causality when you send a message to [vline~] it is scheduled to the next dsp-block (sample accurateley); the last one is already done when you send a message to [vsnapshot~] it operates on the last dsp-block; the next one does not yet exist this is somehow logical: when you query [vsnapshot~] you do want the result immediately (because that's the way how messages are handled in pd); the only result it can give you, is that of already known samples. the only way to overcome this, is by delaying the sampling bang by one dsp-block. the other thing with the irregularities is simpler: even when messages have sub-sample accuracy, the signal-vectors are only sample-accurate. so when you read the sample-values of a sawtooth immediately after the jump, you will always get different values unless the frequency of your ugen is in sync with your samplerate. see also: shannon's sampling theorem attached is a modified patch fm.asdr IOhannes #N canvas 195 55 722 477 10; #X floatatom 12 296 0 0 0 0 - - -; #X obj 12 279 vsnapshot~; #X msg 72 206 1; #X obj 74 236 vmetro 100; #X msg 42 205 0; #X msg 13 127 bang; #X obj 13 103 loadbang; #X obj 74 255 del; #X obj 192 226 /; #X msg 192 207 64 44.1; #X floatatom 192 247 5 0 0 0 - - -; #X obj 13 226 phasor~; #X msg 70 90 44100 64; #X obj 70 113 /; #X floatatom 70 131 5 0 0 0 - - -; #X obj 13 204 f 10; #X obj 13 185 t a b; #X obj 73 184 t b a; #X msg 119 195 1000 \$1; #X obj 119 212 /; #X obj 119 176 f 10; #X obj 13 156 t a a; #X obj 192 186 loadbang; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 7 0; #X connect 4 0 11 1; #X connect 5 0 21 0; #X connect 6 0 5 0; #X connect 7 0 1 0; #X connect 8 0 10 0; #X connect 9 0 8 0; #X connect 10 0 7 1; #X connect 11 0 1 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 14 0 21 0; #X connect 15 0 11 0; #X connect 16 0 15 0; #X connect 16 1 4 0; #X connect 17 0 2 0; #X connect 17 1 20 0; #X connect 18 0 19 0; #X connect 19 0 3 1; #X connect 20 0 18 0; #X connect 21 0 16 0; #X connect 21 1 17 0; #X connect 22 0 9 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem DL Out Of Date! - FTGL continued
Keep watching and testing the auto-builds, we are working on getting FTGL support working now. .hc On Apr 30, 2007, at 8:31 AM, timon wrote: Hi, I posted some q's about GEM and FTGL issues some weeks back. Cause I dont compile myself, I rely on the extended package. I couldnt find anything on the PD official web site for downloading the latest GEM. Nice enough though, someone pointed me to the GEM download centre, http://gem.iem.at/download.html I downloaded the latest OSX binaries. Then I replaced the gem_darwin inside the latest HCS package (open package contents). To my surprise it worked, but to my disappointment, its a 3 year old release! GEM: Graphics Environment for Multimedia GEM: ver: 0.90 release GEM: compiled: May 25 2004 Is there anywhere I can find a recent version of GEM, for OSX G4, that is compiled WITH FTGL? Well, thanks. Timon .. .. BotezCo Co/Timon Botez www.botezco.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cyclone/counter bug
I think there is a bug in the tracker, if not please file one. .hc On May 5, 2007, at 6:59 PM, Kyle Klipowicz wrote: Hi listers~ I'm trying to use cyclone/counter to manipulate video. I know all about making your own counters and such, but at this point I just want something to play my videos with the methods included in the cyclone counter, so why reinvent the wheel, right? (Especially when doing updown counting, anyone w/ an elegant, no spaghetti solution?) So I came across a bug, in that setting the min value of the counter has no effect, it always ranges between zero and the max value. I am using Pd-0.39.2-extended-rc1 on OS X 10.4.9. Thank you! ~Kyle -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Mon, 2007-05-07 at 12:58 +0200, IOhannes m zmoelnig wrote: when you send a message to [vline~] it is scheduled to the next dsp-block (sample accurateley); the last one is already done when you send a message to [vsnapshot~] it operates on the last dsp-block; the next one does not yet exist this is somehow logical: when you query [vsnapshot~] you do want the result immediately (because that's the way how messages are handled in pd); the only result it can give you, is that of already known samples. thanks, it seems logical for me now... the only way to overcome this, is by delaying the sampling bang by one dsp-block. the other thing with the irregularities is simpler: even when messages have sub-sample accuracy, the signal-vectors are only sample-accurate. so when you read the sample-values of a sawtooth immediately after the jump, you will always get different values unless the frequency of your ugen is in sync with your samplerate. see also: shannon's sampling theorem ah, i see. from what i expected from [vsnapshot~] before, it should have used some kind of interpolation, that it obviously does not have. now it is also clear for me, why the discontinuousities grew with higher frequencies/smaller periods. attached is a modified patch what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro]. 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
[PD] [troute] is a multiple-argument list-settable route.
Don't bother: [sroute] is part of [list]-abs. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ I guess I meant a version that could accept multiple targets a la vanilla [route] and add/subtract outlets accordingly. But, now that I've actually built it, I have no idea why one would want to do such a thing. Regardless, [troute] is capable of adding (but not subtracting) outlets to itself to accomadate longer target lists than it was called with. (Get it? Adding that functionality was like swimming upstream! Sigh.) Shorter argument lists after longer ones will just leave crufty useless outlets. It is still hopefully a useful object for fixed argument counts, though in that case it should probably be called like [troute x x x x] and set via right inlet to avoid confusing people terribly. Cheers Luke troute.pd Description: Binary data troute-help.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [declare]: -path seems not to be added to the searchpathes
hi i cannot get [declare]'s -path-flag working. i tried relative pathes as well as absolute ones. e.g. i have a file: /home/roman/netpd/abs/netpd-r i made a [declare -path /home/roman/netpd/abs], then i tried to instantiate a [netpd-r], but pd -verbose prints the following pathes: tried /home/roman/netpd/patches/netpd-r.l_i386 and failed tried /usr/local/lib/pd/extra/netpd-r.l_i386 and failed tried /home/roman/netpd/patches/netpd-r.pd_linux and failed tried /usr/local/lib/pd/extra/netpd-r.pd_linux and failed tried /home/roman/netpd/patches/netpd-r/netpd-r.l_i386 and failed tried /usr/local/lib/pd/extra/netpd-r/netpd-r.l_i386 and failed tried /home/roman/netpd/patches/netpd-r/netpd-r.pd_linux and failed tried /usr/local/lib/pd/extra/netpd-r/netpd-r.pd_linux and failed tried /home/roman/netpd/patches/netpd-r.pd and failed tried /usr/local/lib/pd/extra/netpd-r.pd and failed tried /home/roman/netpd/patches/netpd-r.pat and failed tried /usr/local/lib/pd/extra/netpd-r.pat and failed netpd-r ... couldn't create /home/roman/netpd/abs doesn't show up in the pathes. why? am i doing something wrong? i am on miller's pd 0.40.2 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] Sending data from PD to another program
I thought of something like your solution too, Frank, I'll have to give it an inspection after I get off work. As for my own solution, I decided that it could be very useful for Markov Chain / random walk type of operations, especially when they are more cyclical and NOT tree structures. For a smaller number of states, say under 20, it would be really easy to prototype using the node method where you simply chain things together. In fact, an AI generative music machine would greatly benefit from being able to do such a walk. However, is there any method for making dynamic select and number of outlets in a node, without coding an external? Or would it be simpler to hard-code the node abstraction with more outlets and let the user choose to use less? Also, I decided it would be nice to have node names in some kind of namespace for the node, where it has the form 'name.message'. The idea is that while the name might be unique, messages might not. This would make it easy to write linear chord structures as a chain of dataflow objects. So I'm trying to remember, can .39 vanilla PD split a symbol based on some delimiter, such as '.' (decimal) ? It seems like I rely on zexy for things like this sometimes! Or do I need to give the abstraction both a name, and a message parameter? ~David On 5/7/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, David Powers hat gesagt: // David Powers wrote: Here you go, just use the tree abstraction and create named nodes for every event in your story! Note that the nodes are hard coded to send to master, you'd want another master receiver for your GEM abstraction to select the image which goes with the current node. Oh, and of course replace the PD selector patch, which sends random 0 or 1, with your actual voting mechanism. ~David On 5/6/07, David Powers [EMAIL PROTECTED] wrote: I think I will try to do a quick prototype and email it to you in 15-20 minutes. ~David On 5/6/07, Jared [EMAIL PROTECTED] wrote: David, Thanks for the reply. That's basically what I want to do. My concern is that there are around 80 nodes which have to be displayed in specific if-then sequences (if it's at node 12 and the vote is A, go to node 33, if the vote is B go to node 37). My understanding of PD means this isn't *impossible*, it'll just be a bit clunky. If you have any suggestions to the contrary, I'd love to hear 'em. I attached another solution to your problem, which may be easier to extend to 80 nodes, because not much patching is involved, instead you write a textfile with a definition of your state transitions (because basically what you seem to long for is just that: a state machine). The idea is to write a textfile where every line represents a certain state of your system indicated by the line number. The content of a line then specifies the possible transitions. In the example patch every state has two possible follow-up states written as numbers. Depending on the choice of a user (0 or 1 in the example) a new state is selected by selecting either the first or the second follow-up state and making that the new active state. Ciao -- Frank Barknecht _ __footils.org_ __goto10.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] accuracy of signal/message-objects
two side questions: 1) since computers are much faster now than in 1998, would it be possible to change the 64 sample block timing of messages to a block~ 1 and use block~ 64 only for talking to the soundcard? 2) Is it possible to get microsecond accuracy in metro? the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference. marius. Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [declare]: -path seems not to be added to the searchpathes
Roman Haefeli wrote: hi i cannot get [declare]'s -path-flag working. i tried relative pathes as well as absolute ones. oh yes, i forgot: that's a problem with [declare]; it only gets executed when the patch is loaded mfg.adsr IOhanens ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Roman Haefeli wrote: what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro]. oh yes, i forgot. [vmetro] is just a [metro] replacement based on [delay] so i can use small cycles (1ms); you can safely replace it with [metro]. mfgaösdr IOhanens ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, marius schebella hat gesagt: // marius schebella wrote: two side questions: 1) since computers are much faster now than in 1998, would it be possible to change the 64 sample block timing of messages to a block~ 1 and use block~ 64 only for talking to the soundcard? Messages already are faster than [block~ 1]. It's only the conversion from messages to signals (and the other way around) that's tricky. However doing all signal processing at [block~ 1] even today is quite a burden - and even an unnecessary one in many cases. Just try it. 2) Is it possible to get microsecond accuracy in metro? the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference. metro handles float periods just fine. Try: [metro 200.5] | [t b b] || [timer] | [200.5\ Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] flatspace externals in ext39.2
On May 7, 2007, at 4:58 AM, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: simon wise wrote: On 5 May 2007, at 5:14 AM, Hans-Christoph Steiner wrote: [classpath] == [declare -stdpath] Adds a path to the global search path. thats great! - I wasn't aware of [classpath] -- now I can stop wrangling preferences/users trying to get different paths and libraries for different versions. I hope there are plans for inclusion in the miller pd distribution soon (though a least it is fairly easy to explain how to add them, even to a novice user). hmm, i don't fully understand your request: hans just told you that [classpath] (an external) is basically the same as [decalre -stdpath] (which comes with pd-vanilla) Actually I now found that [classpath] according to the help-file in CVS/externals/hcs/classpath-help.pd does something different than [declare -stdpath]: It's not used to *set* the path, but to *get* the searchpath with an interface similar to [textfile]: Each bang sent to [classpath] will make it print the next entry in the current Pd path. So it's actually not intended for making adjustments to the path, that's left to [declare]. Actually, it is intended both to set the global search path (aka classpath, aka [declare -stdpath]), but it also allows you to query the global search path. [import] will allow querying. That's the intention at least. I haven't looked at it in a bit, so they do not fully live up to those claims yet. I think I was waiting for somethings from Miller to settle before taking it up again. About putting the [declare] object first, I haven't figured that part out yet. Plus the [declare] ordering was limited/buggy last I checked (a few months ago?) .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_set in RGB mode
Thanks, It works perfect! Nicolas IOhannes m zmoelnig a écrit : Nicolas Montgermont wrote: Hi list, I try to control the color of pixels using [pix_set], the object works well but there is a behavior that I want to change: when you set the color of a pixel, it is calculating a kind of interpolation with the neighbours, is it possible to plot it like a simple square, without any interpolation? send [quality 0( to [pix_texture] mfg.asdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Nicolas Montgermont - PhD Student http://nicomon.basseslumieres.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Mon, 2007-05-07 at 16:57 +0200, IOhannes m zmoelnig wrote: Roman Haefeli wrote: what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro]. oh yes, i forgot. [vmetro] is just a [metro] replacement based on [delay] so i can use small cycles (1ms); you can safely replace it with [metro]. I've always wondered this: what does the 'v' stand for in [vline~] [vsnapshot~] etc. ..? Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] New to PD on Mac OSX-Output makes
On May 7, 2007, at 2:22 AM, simon wise wrote: On 6 May 2007, at 7:11 PM, Tuomas Brock wrote: spits out these rythmic blips. So it goes blip..blip..blip etc etc etc search the archives of this list http://lists.puredata.info/pipermail/ pd-list/ this exact problem, and a solution, has come up several times (but I have never experienced the problem and I've used many new and old Macs). Using JackOSX as the audio interface has lots of advantages in OSX (and is said to be more stable in Pd), I always use it. Download from http://www.jackosx.com/. That sounds like this bug: http://sourceforge.net/tracker/index.php? func=detailaid=1561839group_id=55736atid=478070 There is a workaround listen there. .hc simon ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] mod~ ???
I'm grinding my teeth trying to work out an audio signal version of [mod]. I have a [phasor~]-driven looping abstraction with a variable loop point, but sometimes the parameters I send it cause it to go past the end of the table, resulting in silence when I'd rather it started playing immediately from the start of the table again. Is there some way to get the audio signal number to wrap back around to 0 (i.e the start of the table) after it passes a given value (i.e. the end of the table)? [wrap~] doesn't do the trick, BTW. best, d. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 105: Listen to the quiet voice ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
Derek Holzer wrote: end of the table)? [wrap~] doesn't do the trick, BTW. i am sure it does. try scaling the signal before sending it to [wrap~] and afterwards undo the scaling. [/~ 100] | [wrap~] | [*~ 100] mfa.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
I tried this already, and it's not appropriate in this case. The idea is to change the start of the loop to any place in the sample. If the length of the loop is longer than what's left of the sample in the table, currently I get silence. If I use [wrap~] the way you describe it, the loop I select always starts at the beginning of the table, because [wrap~] returns the percentage of the table I have overshot. I need a solution where, if the table is 100 places long, I can loop from 95 back around to 25 if need be. Which is what my theoretical [mod~] would do. But I simply can't wrap my head around how to construct it. Your [wrap~] solution seems to return a loop starting at 0 which is 30 units long instead. best, d. IOhannes m zmoelnig wrote: Derek Holzer wrote: end of the table)? [wrap~] doesn't do the trick, BTW. i am sure it does. try scaling the signal before sending it to [wrap~] and afterwards undo the scaling. [/~ 100] | [wrap~] | [*~ 100] mfa.sdr IOhannes -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 187: Would anybody want it? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
Test patch attached... see the [wraparound~] subpatch for the part which doesn't work yet! d. Derek Holzer wrote: I tried this already, and it's not appropriate in this case. The idea is to change the start of the loop to any place in the sample. If the length of the loop is longer than what's left of the sample in the table, currently I get silence. If I use [wrap~] the way you describe it, the loop I select always starts at the beginning of the table, because [wrap~] returns the percentage of the table I have overshot. I need a solution where, if the table is 100 places long, I can loop from 95 back around to 25 if need be. Which is what my theoretical [mod~] would do. But I simply can't wrap my head around how to construct it. Your [wrap~] solution seems to return a loop starting at 0 which is 30 units long instead. best, d. IOhannes m zmoelnig wrote: Derek Holzer wrote: end of the table)? [wrap~] doesn't do the trick, BTW. i am sure it does. try scaling the signal before sending it to [wrap~] and afterwards undo the scaling. [/~ 100] | [wrap~] | [*~ 100] mfa.sdr IOhannes -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 87: Imagine the music as a moving chain or caterpillar #N canvas 315 27 885 778 10; #X text 240 13 0 - 127; #X text 574 6 0 - 255; #X text 581 45 127 = normal; #X text 580 31 255 = lowest; #X text 584 61 0 = highest; #X obj 91 516 phasor~; #X obj 91 553 *~; #X obj 91 302 / 44.1; #X obj 91 329 expr 1 / ($f1 * 1 / 1000); #X obj 61 247 t f f; #X obj 91 422 sig~; #X obj 91 450 *~; #X text 142 302 time in ms (use 48 if sample rate is 48KHz); #X text 103 245 number of samples in glitch; #X obj 268 116 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X text 241 39 127 = whole sample; #X text 244 60 0 = smallest fraction; #X obj 251 146 / 127; #X obj 61 219 *; #X obj 91 583 +~; #X obj 452 124 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X floatatom 458 193 5 0 0 0 - - -; #X obj 385 234 *; #X obj 581 229 / 127; #X obj 622 134 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X floatatom 595 272 5 0 0 0 - - -; #X obj 598 196 abs; #X obj 599 172 - 255; #X obj 250 175 t b f; #X obj 400 188 t b f; #X floatatom 324 163 5 0 0 0 - - -; #X text 416 14 0 - 127; #X obj 434 153 / 255; #N canvas 0 22 406 310 wraparound~ 0; #X obj 87 29 inlet~; #X obj 87 149 outlet~; #X obj 87 83 wrap~; #X obj 87 55 /~; #X obj 87 113 *~; #X obj 144 28 inlet total num of samples in table; #X connect 0 0 3 0; #X connect 2 0 4 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 5 0 3 1; #X connect 5 0 4 1; #X restore 91 631 pd wraparound~; #X obj 551 383 table test_zample; #X obj 29 21 openpanel; #X obj 30 -8 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 29 49 read -resize \$1 test_zample; #X obj 28 76 soundfiler; #X obj 240 85 inlet loop length; #X obj 393 86 inlet loop offset; #X obj 552 85 inlet loop pitch; #X text 419 33 127 = table start; #X text 420 60 0 = table end; #X obj 91 682 dac~; #X text 121 585 offset loop from start of table; #X text 126 555 multiply phasor~ by loop length; #X text 277 329 convert ms to frequency in Hz; #X text 209 630 --this needs help!! without this subpatch \, loop offset works \, but can go beyond bounds of table. with this subpatch \, loop offset does not work \, so table bounds cannot be reached.; #X connect 5 0 6 0; #X connect 6 0 19 0; #X connect 7 0 8 0; #X connect 8 0 10 0; #X connect 9 0 6 1; #X connect 9 0 33 1; #X connect 9 1 7 0; #X connect 10 0 11 0; #X connect 11 0 5 0; #X connect 14 0 17 0; #X connect 14 0 30 0; #X connect 17 0 28 0; #X connect 18 0 9 0; #X connect 19 0 33 0; #X connect 20 0 32 0; #X connect 22 0 19 1; #X connect 23 0 25 0; #X connect 23 0 11 1; #X connect 24 0 27 0; #X connect 26 0 23 0; #X connect 27 0 26 0; #X connect 28 0 18 0; #X connect 28 1 18 1; #X connect 29 0 22 0; #X connect 29 1 22 1; #X connect 32 0 21 0; #X connect 32 0 29 0; #X connect 33 0 44 0; #X connect 33 0 44 1; #X connect 35 0 37 0; #X connect 36 0 35 0; #X connect 37 0 38 0; #X connect 38 0 18 0; #X connect 38 0 22 0; #X connect 39 0 17 0; #X connect 40 0 32 0; #X connect 41 0 27 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ??? [corrected test patch, still needs help]
Sorry, last patch was missing the tabread! Use this one! d. Derek Holzer wrote: Test patch attached... see the [wraparound~] subpatch for the part which doesn't work yet! d. Derek Holzer wrote: I tried this already, and it's not appropriate in this case. The idea is to change the start of the loop to any place in the sample. If the length of the loop is longer than what's left of the sample in the table, currently I get silence. If I use [wrap~] the way you describe it, the loop I select always starts at the beginning of the table, because [wrap~] returns the percentage of the table I have overshot. I need a solution where, if the table is 100 places long, I can loop from 95 back around to 25 if need be. Which is what my theoretical [mod~] would do. But I simply can't wrap my head around how to construct it. Your [wrap~] solution seems to return a loop starting at 0 which is 30 units long instead. best, d. IOhannes m zmoelnig wrote: Derek Holzer wrote: end of the table)? [wrap~] doesn't do the trick, BTW. i am sure it does. try scaling the signal before sending it to [wrap~] and afterwards undo the scaling. [/~ 100] | [wrap~] | [*~ 100] mfa.sdr IOhannes #N canvas 315 27 885 778 10; #X text 240 13 0 - 127; #X text 574 6 0 - 255; #X text 581 45 127 = normal; #X text 580 31 255 = lowest; #X text 584 61 0 = highest; #X obj 91 516 phasor~; #X obj 91 553 *~; #X obj 91 302 / 44.1; #X obj 91 329 expr 1 / ($f1 * 1 / 1000); #X obj 61 247 t f f; #X obj 91 422 sig~; #X obj 91 450 *~; #X text 142 302 time in ms (use 48 if sample rate is 48KHz); #X text 103 245 number of samples in glitch; #X obj 268 116 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X text 241 39 127 = whole sample; #X text 244 60 0 = smallest fraction; #X obj 251 146 / 127; #X obj 61 219 *; #X obj 91 583 +~; #X obj 452 124 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X floatatom 458 193 5 0 0 0 - - -; #X obj 385 234 *; #X obj 581 229 / 127; #X obj 622 134 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X floatatom 595 272 5 0 0 0 - - -; #X obj 598 196 abs; #X obj 599 172 - 255; #X obj 250 175 t b f; #X obj 400 188 t b f; #X floatatom 324 163 5 0 0 0 - - -; #X text 416 14 0 - 127; #X obj 434 153 / 255; #N canvas 0 22 406 310 wraparound~ 0; #X obj 87 29 inlet~; #X obj 87 149 outlet~; #X obj 87 83 wrap~; #X obj 87 55 /~; #X obj 87 113 *~; #X obj 144 28 inlet total num of samples in table; #X connect 0 0 3 0; #X connect 2 0 4 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 5 0 3 1; #X connect 5 0 4 1; #X restore 91 631 pd wraparound~; #X obj 551 383 table test_zample; #X obj 29 21 openpanel; #X obj 30 -8 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 29 49 read -resize \$1 test_zample; #X obj 28 76 soundfiler; #X obj 240 85 inlet loop length; #X obj 393 86 inlet loop offset; #X obj 552 85 inlet loop pitch; #X text 419 33 127 = table start; #X text 420 60 0 = table end; #X obj 91 682 dac~; #X text 121 585 offset loop from start of table; #X text 126 555 multiply phasor~ by loop length; #X text 277 329 convert ms to frequency in Hz; #X text 209 630 --this needs help!! without this subpatch \, loop offset works \, but can go beyond bounds of table. with this subpatch \, loop offset does not work \, so table bounds cannot be reached.; #X connect 5 0 6 0; #X connect 6 0 19 0; #X connect 7 0 8 0; #X connect 8 0 10 0; #X connect 9 0 6 1; #X connect 9 0 33 1; #X connect 9 1 7 0; #X connect 10 0 11 0; #X connect 11 0 5 0; #X connect 14 0 17 0; #X connect 14 0 30 0; #X connect 17 0 28 0; #X connect 18 0 9 0; #X connect 19 0 33 0; #X connect 20 0 32 0; #X connect 22 0 19 1; #X connect 23 0 25 0; #X connect 23 0 11 1; #X connect 24 0 27 0; #X connect 26 0 23 0; #X connect 27 0 26 0; #X connect 28 0 18 0; #X connect 28 1 18 1; #X connect 29 0 22 0; #X connect 29 1 22 1; #X connect 32 0 21 0; #X connect 32 0 29 0; #X connect 33 0 44 0; #X connect 33 0 44 1; #X connect 35 0 37 0; #X connect 36 0 35 0; #X connect 37 0 38 0; #X connect 38 0 18 0; #X connect 38 0 22 0; #X connect 39 0 17 0; #X connect 40 0 32 0; #X connect 41 0 27 0; -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 129: Put in earplugs #N canvas 334 83 885 778 10; #X text 240 13 0 - 127; #X text 574 6 0 - 255; #X text 581 45 127 = normal; #X text 580 31 255 = lowest; #X text 584 61 0 = highest; #X obj 91 516 phasor~; #X obj 91 553 *~; #X obj 91 302 / 44.1; #X obj 91 329 expr 1 / ($f1 * 1 / 1000); #X obj 61 247 t f f; #X obj 91 422 sig~; #X obj 91 450 *~; #X text 142 302 time in ms (use 48 if sample rate is 48KHz); #X obj 268 116 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X text 241 39 127 = whole sample; #X text 244 60 0 = smallest fraction; #X obj 251 146 / 127; #X obj 61 219 *; #X obj 91 583 +~; #X obj 452 124 hsl 128 15 0 255 0 0 empty empty empty -2 -6
Re: [PD] mod~ ???
hi derek i attached a patch, that should do what you want. it is a modified version of IOhannes approach, but it is still only a [wrap~] with scaling functionality. roman On Mon, 2007-05-07 at 19:00 +0200, Derek Holzer wrote: I tried this already, and it's not appropriate in this case. The idea is to change the start of the loop to any place in the sample. If the length of the loop is longer than what's left of the sample in the table, currently I get silence. If I use [wrap~] the way you describe it, the loop I select always starts at the beginning of the table, because [wrap~] returns the percentage of the table I have overshot. I need a solution where, if the table is 100 places long, I can loop from 95 back around to 25 if need be. Which is what my theoretical [mod~] would do. But I simply can't wrap my head around how to construct it. Your [wrap~] solution seems to return a loop starting at 0 which is 30 units long instead. best, d. IOhannes m zmoelnig wrote: Derek Holzer wrote: end of the table)? [wrap~] doesn't do the trick, BTW. i am sure it does. try scaling the signal before sending it to [wrap~] and afterwards undo the scaling. [/~ 100] | [wrap~] | [*~ 100] mfa.sdr IOhannes #N canvas 684 414 423 469 10; #X obj 35 173 /~; #X obj 36 223 *~; #X obj 36 200 wrap~; #X floatatom 115 79 5 0 0 0 - - -; #X floatatom 235 77 5 0 0 0 - - -; #X obj 36 139 -~; #X obj 115 106 f; #X obj 115 162 -; #X obj 115 137 t b f; #X obj 36 245 +~; #X obj 35 39 sig~; #X floatatom 35 16 5 0 0 0 - - -; #X obj 44 329 loadbang; #X obj 44 350 metro 100; #X obj 37 376 snapshot~; #X floatatom 37 400 5 0 0 0 - - -; #X text 114 54 start point; #X text 234 57 end point; #X connect 0 0 2 0; #X connect 1 0 9 0; #X connect 2 0 1 0; #X connect 3 0 6 0; #X connect 4 0 7 0; #X connect 5 0 0 0; #X connect 6 0 8 0; #X connect 6 0 5 1; #X connect 6 0 9 1; #X connect 7 0 0 1; #X connect 7 0 1 1; #X connect 8 0 7 0; #X connect 8 1 7 1; #X connect 9 0 14 0; #X connect 10 0 5 0; #X connect 11 0 10 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 14 0 15 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
marius schebella wrote: 2) Is it possible to get microsecond accuracy in metro? the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference. marius. [metro] is very accurate over time, it just has a jitter as the bangs have to happen in between sample blocks, but if you measure over say one hour the timing is very accurate. I can run a hydrogen drum pattern with a pd midi patch both running at the same tempo and they stay in sync all day long, (or until hydrogen crashes because of its outrageously photorealist gui...I generally run with all windows minimized.) Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [declare]: -path seems not to be added to the searchpathes
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Mon, 2007-05-07 at 16:58 +0200, IOhannes m zmoelnig wrote: Roman Haefeli wrote: hi i cannot get [declare]'s -path-flag working. i tried relative pathes as well as absolute ones. oh yes, i forgot: that's a problem with [declare]; it only gets executed when the patch is loaded ah, ok. thanks. however, it works only for the patch, that is containing the [declare]-object, whereas at the same time a [declare -lib /path/to/somelib] makes the objects from the external somelib available for all patches running in the same instance of pd. isn't that kind of inconsistent? This clearly is a bug in [declare]. I now filed a bug report regarding this behaviour with ID 1714473. Attached is the example I used to illustrate the bug. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ declare-test.tgz Description: GNU Unix tar archive ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ??? [almost there, but not quite!]
Hi Roman, and thanks. I implemented it in my patch, but it doesn't seem to work right. The looping isn't seamless, in fact there's a hiccup at the point where the loop wraps around. In my previous version, I had another function to calculate the offset and start point, so what would work better for me is the the original concept, of an audio [mod~] which would only wrap around the end point of the table. Try for yourself and see with the attached patch. d. Roman Haefeli wrote: hi derek i attached a patch, that should do what you want. it is a modified version of IOhannes approach, but it is still only a [wrap~] with scaling functionality. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 61: Don't be frightened of cliches #N canvas 39 22 889 782 10; #X text 240 13 0 - 127; #X text 574 6 0 - 255; #X text 581 45 127 = normal; #X text 580 31 255 = lowest; #X text 584 61 0 = highest; #X obj 91 516 phasor~; #X obj 91 553 *~; #X obj 91 302 / 44.1; #X obj 91 329 expr 1 / ($f1 * 1 / 1000); #X obj 61 247 t f f; #X obj 91 422 sig~; #X obj 91 450 *~; #X text 142 302 time in ms (use 48 if sample rate is 48KHz); #X obj 268 116 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 7400 1; #X text 241 39 127 = whole sample; #X text 244 60 0 = smallest fraction; #X obj 251 146 / 127; #X obj 61 219 *; #X obj 452 124 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 12000 1; #X floatatom 458 193 5 0 0 0 - - -; #X obj 385 234 *; #X obj 581 229 / 127; #X obj 622 134 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 6400 1; #X floatatom 595 272 5 0 0 0 - - -; #X obj 598 196 abs; #X obj 599 172 - 255; #X obj 250 175 t b f; #X obj 400 188 t b f; #X floatatom 324 163 5 0 0 0 - - -; #X obj 434 153 / 255; #X obj 551 383 table test_zample; #X obj 29 21 openpanel; #X obj 30 -8 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 29 49 read -resize \$1 test_zample; #X obj 28 76 soundfiler; #X obj 240 85 inlet loop length; #X obj 393 86 inlet loop offset; #X obj 552 85 inlet loop pitch; #X text 420 60 0 = table end; #X obj 91 712 dac~; #X text 126 555 multiply phasor~ by loop length; #X text 277 329 convert ms to frequency in Hz; #X text 103 245 number of samples in loop; #X text 416 16 0 - 255; #X text 419 32 255 = table start; #X obj 91 688 tabread4~ test_zample; #N canvas 582 348 512 453 wraparound~ 0; #X obj 22 42 inlet~; #X obj 22 296 outlet~; #X obj 22 182 /~; #X obj 22 232 *~; #X obj 22 209 wrap~; #X obj 22 98 -~; #X obj 101 65 f; #X obj 101 121 -; #X obj 101 96 t b f; #X obj 22 254 +~; #X obj 100 41 inlet start point; #X obj 233 41 inlet end point; #X text 86 266 thanks to Roman Haefeli for helping with this part; #X connect 0 0 5 0; #X connect 2 0 4 0; #X connect 3 0 9 0; #X connect 4 0 3 0; #X connect 5 0 2 0; #X connect 6 0 8 0; #X connect 6 0 5 1; #X connect 6 0 9 1; #X connect 7 0 2 1; #X connect 7 0 3 1; #X connect 8 0 7 0; #X connect 8 1 7 1; #X connect 9 0 1 0; #X connect 10 0 6 0; #X connect 11 0 7 0; #X restore 91 605 pd wraparound~; #X obj 184 466 mod; #X obj 184 442 +; #X obj 184 408 t b f; #X text 221 606 ---Roman's [wrap~] implementation \, but the wraparound point hiccups and I can't figure out why!; #X connect 5 0 6 0; #X connect 6 0 46 0; #X connect 7 0 8 0; #X connect 8 0 10 0; #X connect 9 0 6 1; #X connect 9 1 7 0; #X connect 10 0 11 0; #X connect 11 0 5 0; #X connect 13 0 16 0; #X connect 13 0 28 0; #X connect 16 0 26 0; #X connect 17 0 9 0; #X connect 17 0 48 0; #X connect 18 0 29 0; #X connect 20 0 46 1; #X connect 20 0 49 0; #X connect 21 0 23 0; #X connect 21 0 11 1; #X connect 22 0 25 0; #X connect 24 0 21 0; #X connect 25 0 24 0; #X connect 26 0 17 0; #X connect 26 1 17 1; #X connect 27 0 20 0; #X connect 27 1 20 1; #X connect 29 0 19 0; #X connect 29 0 27 0; #X connect 31 0 33 0; #X connect 32 0 31 0; #X connect 33 0 34 0; #X connect 34 0 17 0; #X connect 34 0 20 0; #X connect 34 0 47 1; #X connect 35 0 16 0; #X connect 36 0 29 0; #X connect 37 0 25 0; #X connect 45 0 39 0; #X connect 46 0 45 0; #X connect 47 0 46 2; #X connect 48 0 47 0; #X connect 49 0 48 0; #X connect 49 1 48 1; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote: Test patch attached... see the [wraparound~] subpatch for the part which doesn't work yet! I added a [tabread4~ test_zample] and now it works. ;) Now seriously: The forgotten tabread probably wasn't the error you were looking for. But here the patch now works as advertised: Setting loop offset to nearly the end of the sample will indeed wrap around to the start of the sample and play from there just fine. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ variable_loop_point-new.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Instance]
Yes, but good luck actually being able to use the toxy library out of box! ~Kyle On 5/4/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: On May 3, 2007, at 11:56 PM, Chris McCormick wrote: On Thu, May 03, 2007 at 03:10:16PM +0200, Roman Haefeli wrote: On Thu, 2007-05-03 at 02:01 -0700, Luke Iannini (pd) wrote: thanks to [closebang]). i vote for including [closebang] into pd vanilla. is there any chance, that it will be included? that is one of the most wanted missing objects for me. I second that vote. Would love to see a 'savebang' too. That would really help with the state saving stuff. It should go off after ctrl-S or 'Save' menu item is selected, but before the save is performed. You can already do that with a little help from [toxy/tot], see attached. .hc Chris. --- http://mccormick.cx ___ 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 -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
Hi Frank, thanks for helping. This is the solution I tried at first. However, with this every loop starts at the beginning of the table, no matter where I set the loop offset. I'm assuming you actually tested it before posting, so are there different versions of [wrap~] perhaps? d. Frank Barknecht wrote: Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote: Test patch attached... see the [wraparound~] subpatch for the part which doesn't work yet! I added a [tabread4~ test_zample] and now it works. ;) Now seriously: The forgotten tabread probably wasn't the error you were looking for. But here the patch now works as advertised: Setting loop offset to nearly the end of the sample will indeed wrap around to the start of the sample and play from there just fine. Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 190: You can only make one dot at a time ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote: Test patch attached... see the [wraparound~] subpatch for the part which doesn't work yet! I added a [tabread4~ test_zample] and now it works. ;) Now seriously: The forgotten tabread probably wasn't the error you were looking for. But here the patch now works as advertised: Setting loop offset to nearly the end of the sample will indeed wrap around to the start of the sample and play from there just fine. Ah, sorry: I now read, that you don't want to start at the beginning of the sample but at the offset-point again. Then some more math is needed, I'll give it a shot a bit later. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
Yes, correct. If I have a table that's 100 places long, and I set the offset to 95 and the length to 25, I would like to get a loop that starts at 95 and when it reaches 100, continue playing at 0 up to 25. The next loop would then begin again at 95 and wrap around through 0 to 25, und so weiter. best, d. Frank Barknecht wrote: Ah, sorry: I now read, that you don't want to start at the beginning of the sample but at the offset-point again. Then some more math is needed, I'll give it a shot a bit later. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 172: Use `unqualified' people ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Instance]
As far as I know, [tot] is quite stable, at least in the context of Pd-extended. If anyone has a problems with it, please file a bug report. .hc On May 7, 2007, at 2:09 PM, Kyle Klipowicz wrote: Never mind, that one actually worked for me. But the tot examples are not loaded when using Pd-0.39.2-extended-rc2.app on OS X 10.4.9. I'll file a bug in the tracker? ~Kyle On 5/7/07, Kyle Klipowicz [EMAIL PROTECTED] wrote: Yes, but good luck actually being able to use the toxy library out of box! ~Kyle On 5/4/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: On May 3, 2007, at 11:56 PM, Chris McCormick wrote: On Thu, May 03, 2007 at 03:10:16PM +0200, Roman Haefeli wrote: On Thu, 2007-05-03 at 02:01 -0700, Luke Iannini (pd) wrote: thanks to [closebang]). i vote for including [closebang] into pd vanilla. is there any chance, that it will be included? that is one of the most wanted missing objects for me. I second that vote. Would love to see a 'savebang' too. That would really help with the state saving stuff. It should go off after ctrl-S or 'Save' menu item is selected, but before the save is performed. You can already do that with a little help from [toxy/tot], see attached. .hc Chris. --- http://mccormick.cx ___ 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 -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO [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
Re: [PD] mod~ ???
Sorry! Should read: Yes, correct. If I have a table that's 100 places long, and I set the offset to 95 and the length to 30, I would like to get a loop that starts at 95 and when it reaches 100, continue playing at 0 up to 25. The next loop would then begin again at 95 and wrap around through 0 to 25, und so weiter. apologies, d. Derek Holzer wrote: Yes, correct. If I have a table that's 100 places long, and I set the offset to 95 and the length to 25, I would like to get a loop that starts at 95 and when it reaches 100, continue playing at 0 up to 25. The next loop would then begin again at 95 and wrap around through 0 to 25, und so weiter. best, d. Frank Barknecht wrote: Ah, sorry: I now read, that you don't want to start at the beginning of the sample but at the offset-point again. Then some more math is needed, I'll give it a shot a bit later. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 175: What are the sections sections of? Imagine a caterpillar moving ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Toxy (was Re: [Instance])
You are right, I just started looking through the Toxy library examples, and so far it looks really nice! I'm excited about this! How do these sliders and such compare with the iemgui objects in terms of gridlock? ~Kyle On 5/7/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: As far as I know, [tot] is quite stable, at least in the context of Pd-extended. If anyone has a problems with it, please file a bug report. .hc On May 7, 2007, at 2:09 PM, Kyle Klipowicz wrote: Never mind, that one actually worked for me. But the tot examples are not loaded when using Pd-0.39.2-extended-rc2.app on OS X 10.4.9. I'll file a bug in the tracker? ~Kyle On 5/7/07, Kyle Klipowicz [EMAIL PROTECTED] wrote: Yes, but good luck actually being able to use the toxy library out of box! ~Kyle On 5/4/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: On May 3, 2007, at 11:56 PM, Chris McCormick wrote: On Thu, May 03, 2007 at 03:10:16PM +0200, Roman Haefeli wrote: On Thu, 2007-05-03 at 02:01 -0700, Luke Iannini (pd) wrote: thanks to [closebang]). i vote for including [closebang] into pd vanilla. is there any chance, that it will be included? that is one of the most wanted missing objects for me. I second that vote. Would love to see a 'savebang' too. That would really help with the state saving stuff. It should go off after ctrl-S or 'Save' menu item is selected, but before the save is performed. You can already do that with a little help from [toxy/tot], see attached. .hc Chris. --- http://mccormick.cx ___ 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 -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO [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 -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Space Invaders 4D Game
I'm just starting out in PD but 99.9% of the time I can break something down and figure out how it works or find something online, but can someone explain to me how to use two gemheads to render a pattern with just on geo. I understand the textfile object and the text file part what I down get is why it works. Thanks, Alain From: Frank Barknecht [EMAIL PROTECTED] Date: 2007/05/05 Sat AM 04:58:59 EDT To: pd-list@iem.at Subject: Re: [PD] Space Invaders 4D Game Hallo, Thomas Ouellet Fredericks hat gesagt: // Thomas Ouellet Fredericks wrote: Your code could be greatly simplified if you used lists to trigger the line objects (for example, sending the message 0,1 1000 will start from 0 then ramp up to 1 in 1 second). I also did a simplification to this nice game: I change the invader.pd to use an external file for the model of the aliens. It's attached as invader2.pd ready to be dropped in as replacement for invader.pd (only used in enemytest). Make sure, the invader.txt file is next to it. Regarding the format of invader.txt: It uses coordinates starting in the lower left corner, so the origin (0,0) is not the center of the invader. To correct that a line with offset num num is used. The spread between the individual pixels can be set in a similar way with spread. See attached xcf-image (for gimp) for how the coordinates were written. Oh, and of course I added an explosion. ;) But explosions have to be implemented in the main game first (that is, the destroy message must not move the invader out of sight, otherwise the nice explosion will stay invisible. I leave that as an excercise for the reader. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ??? [almost there, but not quite!]
Derek Holzer wrote: Hi Roman, and thanks. I implemented it in my patch, but it doesn't seem to work right. The looping isn't seamless, in fact there's a hiccup at the point where the loop wraps around. In my previous version, I had another function to calculate the offset and start point, so what would work better for me is the the original concept, of an audio [mod~] which would only wrap around the end point of the table. like this? mfg.asdr IOhannes #N canvas 509 102 698 619 10; #X obj 338 88 table sample; #X obj 47 95 soundfiler; #X floatatom 47 112 0 0 0 0 - - -; #X text 158 116 lenght in samples; #X obj 46 387 dac~; #X obj 46 357 tabread4~ sample; #X msg 14 91 bang; #N canvas 578 50 639 478 tabreader 0; #X obj 142 451 outlet~; #X obj 93 40 inlet looplength[samples]; #X obj 142 295 *~ 44100; #X obj 141 130 t f b; #X obj 166 148 samplerate~; #X obj 141 163 /; #X obj 141 98 t f f; #X msg 141 183 1 \$1; #X obj 141 259 phasor~ 1; #X obj 141 200 /; #X obj 143 369 /~ 44100; #X obj 143 406 *~ 44100; #X obj 143 387 wrap~; #X obj 186 352 t f f; #X obj 142 278 *~ 1; #X obj 237 189 t b f; #X obj 143 312 +~ 0; #X obj 93 59 route filelength length offset speed bang; #X msg 285 82 0; #X obj 141 236 * 1; #X connect 1 0 17 0; #X connect 2 0 16 0; #X connect 3 0 5 0; #X connect 3 1 4 0; #X connect 4 0 5 1; #X connect 5 0 7 0; #X connect 6 0 3 0; #X connect 6 1 2 1; #X connect 7 0 9 0; #X connect 8 0 14 0; #X connect 9 0 19 0; #X connect 10 0 12 0; #X connect 11 0 0 0; #X connect 12 0 11 0; #X connect 13 0 10 1; #X connect 13 1 11 1; #X connect 14 0 2 0; #X connect 15 0 19 0; #X connect 15 1 19 1; #X connect 16 0 10 0; #X connect 17 0 13 0; #X connect 17 1 6 0; #X connect 17 2 16 1; #X connect 17 3 15 0; #X connect 17 4 18 0; #X connect 18 0 8 1; #X connect 19 0 8 0; #X restore 47 339 pd tabreader; #X msg 152 327 speed \$1; #X floatatom 156 303 5 0 0 0 - - -; #X msg 258 236 offset \$1; #X floatatom 343 263 5 0 0 0 - - -; #X msg 263 191 length 62079; #X msg 66 253 bang; #X floatatom 343 295 0 0 0 0 - - -; #X msg 47 78 read -resize \$1 sample; #X msg 54 29 bang; #X symbolatom 96 27 10 0 0 0 - - -; #X msg 256 210 length 220500; #X msg 393 277 bang; #X obj 46 60 symbol zexy.wav; #X obj 182 36 openpanel; #X obj 181 9 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 100 254 restart loop; #X obj 343 278 * 44100; #X text 348 212 loop length; #X text 328 239 loop offset; #X msg 47 145 filelength \$1 \, offset 0 \, length \$1; #X connect 1 0 2 0; #X connect 2 0 27 0; #X connect 5 0 4 0; #X connect 5 0 4 1; #X connect 6 0 2 0; #X connect 7 0 5 0; #X connect 8 0 7 0; #X connect 9 0 8 0; #X connect 10 0 7 0; #X connect 11 0 24 0; #X connect 12 0 7 0; #X connect 13 0 7 0; #X connect 14 0 10 0; #X connect 15 0 1 0; #X connect 16 0 20 0; #X connect 17 0 20 0; #X connect 18 0 7 0; #X connect 19 0 14 0; #X connect 20 0 15 0; #X connect 21 0 20 0; #X connect 22 0 21 0; #X connect 24 0 14 0; #X connect 27 0 7 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd object for wii remote?
hello list, this is my first time using this list. there is any object to receive data in pd from a wii remote? like this object http://www.iamas.ac.jp/~aka/max/ (the author of this object publish the source code, how this object can it be converted to pd?) how can i get data from wii remote using pd? _ Moda para esta temporada. Ponte al día de todas las tendencias. http://www.msn.es/Mujer/moda/default.asp ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd object for wii remote?
hello list, this is my first time using this list. there is any object to receive data in pd from a wii remote? like this object http://www.iamas.ac.jp/~aka/max/ (the author of this object publish the source code, how this object can it be converted to pd?) how can i get data from wii remote using pd? _ Acepta el reto MSN Premium: Protección para tus hijos en internet. Descárgalo y pruébalo 2 meses gratis. http://join.msn.com?XAPID=1697DI=1055HL=Footer_mailsenviados_proteccioninfantil ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ??? [almost there, but not quite!]
IOhannes m zmoelnig wrote: Derek Holzer wrote: Hi Roman, and thanks. I implemented it in my patch, but it doesn't seem to work right. The looping isn't seamless, in fact there's a hiccup at the point where the loop wraps around. In my previous version, I had another function to calculate the offset and start point, so what would work better for me is the the original concept, of an audio [mod~] which would only wrap around the end point of the table. like this? or to put it in your own words: try and find the difference... mfga.sdr IOhannes #N canvas 334 83 885 778 10; #X text 240 13 0 - 127; #X text 574 6 0 - 255; #X text 581 45 127 = normal; #X text 580 31 255 = lowest; #X text 584 61 0 = highest; #X obj 91 516 phasor~; #X obj 91 553 *~; #X obj 91 302 / 44.1; #X obj 91 329 expr 1 / ($f1 * 1 / 1000); #X obj 61 247 t f f; #X obj 91 422 sig~; #X obj 91 450 *~; #X text 142 302 time in ms (use 48 if sample rate is 48KHz); #X obj 268 116 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X text 241 39 127 = whole sample; #X text 244 60 0 = smallest fraction; #X obj 251 146 / 127; #X obj 61 219 *; #X obj 91 583 +~; #X obj 452 124 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X floatatom 458 193 5 0 0 0 - - -; #X obj 385 234 *; #X obj 581 229 / 127; #X obj 622 134 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X floatatom 595 272 5 0 0 0 - - -; #X obj 598 196 abs; #X obj 599 172 - 255; #X obj 250 175 t b f; #X obj 400 188 t b f; #X floatatom 324 163 5 0 0 0 - - -; #X obj 434 153 / 255; #N canvas 0 22 406 310 wraparound~ 0; #X obj 87 29 inlet~; #X obj 87 149 outlet~; #X obj 87 83 wrap~; #X obj 87 55 /~; #X obj 87 113 *~; #X obj 144 28 inlet total num of samples in table; #X connect 0 0 3 0; #X connect 2 0 4 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 5 0 3 1; #X connect 5 0 4 1; #X restore 91 631 pd wraparound~; #X obj 551 383 table test_zample; #X obj 29 21 openpanel; #X obj 30 -8 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 29 49 read -resize \$1 test_zample; #X obj 28 76 soundfiler; #X obj 240 85 inlet loop length; #X obj 393 86 inlet loop offset; #X obj 552 85 inlet loop pitch; #X text 420 60 0 = table end; #X obj 91 712 dac~; #X text 121 585 offset loop from start of table; #X text 126 555 multiply phasor~ by loop length; #X text 277 329 convert ms to frequency in Hz; #X text 209 630 --this needs help!! without this subpatch \, loop offset works \, but can go beyond bounds of table. with this subpatch \, loop offset does not work \, so table bounds cannot be reached.; #X text 103 245 number of samples in loop; #X text 416 16 0 - 255; #X text 419 32 255 = table start; #X obj 91 688 tabread4~ test_zample; #X connect 5 0 6 0; #X connect 6 0 18 0; #X connect 7 0 8 0; #X connect 8 0 10 0; #X connect 9 0 6 1; #X connect 9 1 7 0; #X connect 10 0 11 0; #X connect 11 0 5 0; #X connect 13 0 16 0; #X connect 13 0 29 0; #X connect 16 0 27 0; #X connect 17 0 9 0; #X connect 18 0 31 0; #X connect 19 0 30 0; #X connect 21 0 18 1; #X connect 22 0 24 0; #X connect 22 0 11 1; #X connect 23 0 26 0; #X connect 25 0 22 0; #X connect 26 0 25 0; #X connect 27 0 17 0; #X connect 27 1 17 1; #X connect 28 0 21 0; #X connect 28 1 21 1; #X connect 30 0 20 0; #X connect 30 0 28 0; #X connect 31 0 49 0; #X connect 33 0 35 0; #X connect 34 0 33 0; #X connect 35 0 36 0; #X connect 36 0 17 0; #X connect 36 0 21 0; #X connect 36 0 31 1; #X connect 37 0 16 0; #X connect 38 0 30 0; #X connect 39 0 26 0; #X connect 49 0 41 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
Hi there, I am not so terribly into that right now.. Just an idea. What if you just shift the table and write it to a second one... silly probably... just an idea Am 07.05.2007 um 20:25 schrieb Derek Holzer: Sorry! Should read: Yes, correct. If I have a table that's 100 places long, and I set the offset to 95 and the length to 30, I would like to get a loop that starts at 95 and when it reaches 100, continue playing at 0 up to 25. The next loop would then begin again at 95 and wrap around through 0 to 25, und so weiter. apologies, d. Derek Holzer wrote: Yes, correct. If I have a table that's 100 places long, and I set the offset to 95 and the length to 25, I would like to get a loop that starts at 95 and when it reaches 100, continue playing at 0 up to 25. The next loop would then begin again at 95 and wrap around through 0 to 25, und so weiter. best, d. Frank Barknecht wrote: Ah, sorry: I now read, that you don't want to start at the beginning of the sample but at the offset-point again. Then some more math is needed, I'll give it a shot a bit later. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 175: What are the sections sections of? Imagine a caterpillar moving ___ 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] mod~ ???
Derek Holzer wrote: Yes, correct. If I have a table that's 100 places long, and I set the offset to 95 and the length to 30, I would like to get a loop that starts at 95 and when it reaches 100, continue playing at 0 up to 25. The next loop would then begin again at 95 and wrap around through 0 to 25, und so weiter. Like this? Note: 0 - [wrap~] - 1, which is weird (and undesirable in my eyes). Claude -- http://claudiusmaximus.goto10.org #N canvas 0 0 387 615 10; #X obj 45 170 phasor~; #X obj 45 283 wrap~; #X obj 46 203 *~ 30; #X obj 45 230 +~ 95; #X obj 45 257 /~ 100; #X obj 45 312 *~ 100; #X floatatom 163 235 5 0 0 1 table-length - -; #X floatatom 164 201 5 0 0 1 offset - -; #X floatatom 165 174 5 0 0 1 loop-length - -; #X obj 45 396 tabread4~ \$0-table 100; #X floatatom 167 145 5 0 0 1 frequency - -; #X obj 45 425 tabsend~ \$0-scope; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-scope 64 float 0; #X coords 0 1 63 -1 64 64 1; #X restore 99 467 graph; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-table 100 float 0; #X coords 0 1 99 -1 100 64 1; #X restore 99 327 graph; #X obj 46 66 samplerate~; #X msg 103 89 0; #X obj 47 42 t b b; #X obj 46 22 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 45 90 / 64; #X msg 166 123 set \$1; #X connect 0 0 2 0; #X connect 1 0 5 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 9 0; #X connect 6 0 4 1; #X connect 6 0 5 1; #X connect 7 0 3 1; #X connect 8 0 2 1; #X connect 9 0 11 0; #X connect 10 0 0 0; #X connect 14 0 18 0; #X connect 15 0 0 1; #X connect 16 0 14 0; #X connect 16 1 15 0; #X connect 17 0 16 0; #X connect 18 0 0 0; #X connect 18 0 19 0; #X connect 19 0 10 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: [metro] is very accurate over time, it just has a jitter as the bangs have to happen in between sample blocks What do you mean by this bangs have to happen in between sample blocks? The bangs from metro AFAIK happen independent from the sample blocks. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toxy (was Re: [Instance])
On Mon May 07, 2007 at 01:26:09PM -0500, Kyle Klipowicz wrote: You are right, I just started looking through the Toxy library examples, and so far it looks really nice! I'm excited about this! How do these sliders and such compare with the iemgui objects in terms of gridlock? you mean like when the widgets stop updating graphically (numbox moves the value but doesnt reflect the changes in the GUI) or something else? it works better than iemgui for effiiency since you can just send over values, instead of drawing instructions which are often 4x as long. as long as you stay within the socket bandwidth limit, i found win32 was the best performer. i mean a scrolling full color 25fps spectrogram was using 2% total CPU, if the task manager is to be believed, on a lowly single-core 2ghz amd64. the same patch on linux has pd and X eaech using like 20% CPU, if top can be believed :/ i'd agree Toxy is pretty nice - its the best youre going to get with the old pd-gui - you get constructors, destructors, all of Tk, and you dont have to know/care how nastily the rest of the GUI is implemented :) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toxy (was Re: [Instance])
One question I have with the toxy sliders is this: in the multiscale-test.pd file, there are some really neat sliders, but how do you create these, and what are the creation arguments? I know that we can just go in to the patch as a text file and get this information, but it would be nice if there were some more instructions on the usage of these really powerful gui tools. What references are recommended for experimenting with this? ~Kyle On 5/7/07, carmen [EMAIL PROTECTED] wrote: On Mon May 07, 2007 at 01:26:09PM -0500, Kyle Klipowicz wrote: You are right, I just started looking through the Toxy library examples, and so far it looks really nice! I'm excited about this! How do these sliders and such compare with the iemgui objects in terms of gridlock? you mean like when the widgets stop updating graphically (numbox moves the value but doesnt reflect the changes in the GUI) or something else? it works better than iemgui for effiiency since you can just send over values, instead of drawing instructions which are often 4x as long. as long as you stay within the socket bandwidth limit, i found win32 was the best performer. i mean a scrolling full color 25fps spectrogram was using 2% total CPU, if the task manager is to be believed, on a lowly single-core 2ghz amd64. the same patch on linux has pd and X eaech using like 20% CPU, if top can be believed :/ i'd agree Toxy is pretty nice - its the best youre going to get with the old pd-gui - you get constructors, destructors, all of Tk, and you dont have to know/care how nastily the rest of the GUI is implemented :) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ??? (FIXED)
I fixed it so it works. Solution is attached. If you are interested in samplers, loading multiple samples, having smooth loop points, sending to multiple targets, etc, you should also check out the sample section of the pdmtl abstractions: http://wiki.dataflow.ws/PdMtlAbstractions/Contents#head-sample Tom CORRECTED variable_loop_point-new.pd #N canvas 315 27 897 843 10; #X text 240 13 0 - 127; #X text 574 6 0 - 255; #X text 581 45 127 = normal; #X text 580 31 255 = lowest; #X text 584 61 0 = highest; #X obj 92 535 phasor~; #X obj 92 348 expr 1 / ($f1 * 1 / 1000); #X obj 92 441 sig~; #X text 115 241 number of samples in glitch; #X obj 268 116 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 1800 1; #X text 241 39 127 = whole sample; #X text 244 60 0 = smallest fraction; #X obj 251 146 / 127; #X obj 78 225 *; #X obj 452 124 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 8500 1; #X floatatom 458 193 5 0 0 0 - - -; #X obj 581 229 / 127; #X obj 622 134 hsl 128 15 0 255 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 5700 1; #X floatatom 595 272 5 0 0 0 - - -; #X obj 598 196 abs; #X obj 599 172 - 255; #X obj 250 175 t b f; #X floatatom 324 163 5 0 0 0 - - -; #X text 416 14 0 - 127; #X obj 434 153 / 255; #X obj 551 383 table test_zample; #X obj 29 21 openpanel; #X obj 30 -8 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 29 49 read -resize \$1 test_zample; #X obj 28 76 soundfiler; #X obj 240 85 inlet loop length; #X obj 393 86 inlet loop offset; #X obj 552 85 inlet loop pitch; #X text 419 33 127 = table start; #X text 420 60 0 = table end; #X text 159 607 offset loop from start of table; #X text 164 577 multiply phasor~ by loop length; #X text 278 348 convert ms to frequency in Hz; #N canvas 0 22 835 552 wraparound~ 0; #X obj 87 29 inlet~; #X obj 87 260 outlet~; #X obj 85 162 wrap~; #X obj 373 258 outlet~; #X obj 86 126 +~ 0; #X obj 689 49 inlet offset; #X obj 87 224 *~ 1; #X obj 417 31 inlet total num of samples in FILE; #X obj 166 30 inlet loop_size; #X obj 86 90 *~ 1; #X connect 0 0 9 0; #X connect 2 0 3 0; #X connect 2 0 6 0; #X connect 4 0 2 0; #X connect 5 0 4 1; #X connect 6 0 1 0; #X connect 7 0 6 1; #X connect 8 0 9 1; #X connect 9 0 4 0; #X restore 92 669 pd wraparound~; #X msg 77 -5 symbol ~/loops; #X obj 93 705 tabread4~ test_zample; #X obj 36 264 t f f b; #X obj 129 287 samplerate~; #X obj 92 321 /; #X text 213 289 YOU WILL AUTOMATICALLY GET THE PROPER SAMPLERATE WITH THIS OBJECT.; #X obj 303 716 snapshot~; #X obj 307 660 loadbang; #X obj 312 686 metro 50; #X obj 307 738 hsl 128 15 0 1 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 10277 1; #X floatatom 75 128 5 0 0 0 - - -; #X obj 270 660 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 93 470 *~ 1; #X obj 252 473 snapshot~; #X obj 256 417 loadbang; #X obj 261 443 metro 50; #X obj 327 497 hsl 128 15 0 1 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 12391 1; #X obj 329 413 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 80 761 dac~; #X obj 138 313 / 1000; #X text 443 737 - This is the part of the file being read.; #X connect 5 0 52 0; #X connect 5 0 38 0; #X connect 6 0 7 0; #X connect 7 0 51 0; #X connect 9 0 12 0; #X connect 9 0 22 0; #X connect 12 0 21 0; #X connect 13 0 41 0; #X connect 14 0 24 0; #X connect 15 0 38 3; #X connect 16 0 18 0; #X connect 16 0 51 1; #X connect 17 0 20 0; #X connect 19 0 16 0; #X connect 20 0 19 0; #X connect 21 0 13 0; #X connect 21 1 13 1; #X connect 21 1 38 1; #X connect 24 0 15 0; #X connect 26 0 28 0; #X connect 27 0 26 0; #X connect 28 0 29 0; #X connect 29 0 13 0; #X connect 29 0 49 0; #X connect 29 0 38 2; #X connect 30 0 12 0; #X connect 31 0 24 0; #X connect 32 0 20 0; #X connect 38 0 40 0; #X connect 38 1 45 0; #X connect 39 0 26 0; #X connect 40 0 57 0; #X connect 40 0 57 1; #X connect 41 1 43 0; #X connect 41 2 42 0; #X connect 42 0 58 0; #X connect 43 0 6 0; #X connect 45 0 48 0; #X connect 46 0 47 0; #X connect 47 0 45 0; #X connect 50 0 47 0; #X connect 51 0 5 0; #X connect 52 0 55 0; #X connect 53 0 54 0; #X connect 54 0 52 0; #X connect 56 0 54 0; #X connect 58 0 43 1; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Mon, 2007-05-07 at 20:59 +0200, Frank Barknecht wrote: Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: [metro] is very accurate over time, it just has a jitter as the bangs have to happen in between sample blocks What do you mean by this bangs have to happen in between sample blocks? The bangs from metro AFAIK happen independent from the sample blocks. in order to make this discussion more confusing, i say: afaik, it depends which object receives the bang from the [metro]. when it is [vline~] or [vsnapshot~], then it is independent from sample blocks, but when the receiver is the phase inlet of an oscillator or [tabwrite~], then the bang happens on the boundaries. personally, i find that a bit confusing and i would like all these objects to behave the same, namely independent from sample blocks. the same two cents again 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] Toxy (was Re: [Instance])
On Mon May 07, 2007 at 02:08:12PM -0500, Kyle Klipowicz wrote: One question I have with the toxy sliders is this: in the multiscale-test.pd file, there are some really neat sliders, but how do you create these, and what are the creation arguments? [widget widgetname widgetref moreargs] where widgetname is the name of the .wid file sans extension and widgetref is any unique symbol I know that we can just go in to the patch as a text file and get this information, but it would be nice if there were some more instructions on the usage of these really powerful gui tools. What references are recommended for experimenting with this? that's probably the most nasty part of toxy, its got its own preprocessing syntax on top of normal TCL with special additions for arguments from pd, widget/canvas IDs, etc, and the widget source code is read by the server, then processed and sent to the client (so scripts longer than the max pd message size get truncated) an autogenerated '--usage' message responder would probably need some hints to be more useful and efficient than just reading the widget's source.. can you instantiate PD objects via right clicking on the canvas yet? toxy registering all the avilable widgets in a user-GUI submenu of that menu's class-browser model sounds like the way to go.. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: I think the bangs are independent but they don't get processed until any pending samples have been dealt with. That was the impression I got when testing [comport] by setting the DTR pin using [metro]: there is always a jitter of a few milliseconds. Maybe it's the OS that causes the jitter, but it was about the same on WinXP and linux. I think, it's comport's fault: [metro] generates clock-delayed messages. These are like messages tagged with a time-stamp referring to Pd's internal clock. However an object needs to actually use the time-stamps and look at the clock to see what time it is. Objects like [vline~] or [delay] do this, but comport doesn't. Also looking at the pd code, as far as I could follow it, the control signals seem to be processed in between signal blocks, so that, for instance, a metro bang that happens in the middle of a signal block will not be processed until after that block, so yes, the metro can tick whenever it wants but the bang won't occur until after the current sample block has been processed. If it happens to tick in between sample blocks then the bang will happen at the correct time. I think, basically that is correct, that's why evaluating the time-stamps of clock-delayed message is important, if you want to avoid jitter. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mod~ ???
On 07/05/2007, at 20.51, Claude Heiland-Allen wrote: Note: 0 - [wrap~] - 1, which is weird (and undesirable in my eyes). Yeah. I still can't translate wrap~ gives the difference between the input and the largest integer not exceeding it to that. The quote is from the help file. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toxy (was Re: [Instance])
There is a fair amount of documentation on the website: http://suita.chopin.edu.pl/~czaja/miXed/externs/toxy.html It would be very handy if you created some better help files for this stuff thru your explorations. I'll happily check them in. Also, if you get really inspired, it would be very nice to figure out how best to integrate these into Pd-extended so that they are easy to use. .hc On May 7, 2007, at 3:08 PM, Kyle Klipowicz wrote: One question I have with the toxy sliders is this: in the multiscale-test.pd file, there are some really neat sliders, but how do you create these, and what are the creation arguments? I know that we can just go in to the patch as a text file and get this information, but it would be nice if there were some more instructions on the usage of these really powerful gui tools. What references are recommended for experimenting with this? ~Kyle On 5/7/07, carmen [EMAIL PROTECTED] wrote: On Mon May 07, 2007 at 01:26:09PM -0500, Kyle Klipowicz wrote: You are right, I just started looking through the Toxy library examples, and so far it looks really nice! I'm excited about this! How do these sliders and such compare with the iemgui objects in terms of gridlock? you mean like when the widgets stop updating graphically (numbox moves the value but doesnt reflect the changes in the GUI) or something else? it works better than iemgui for effiiency since you can just send over values, instead of drawing instructions which are often 4x as long. as long as you stay within the socket bandwidth limit, i found win32 was the best performer. i mean a scrolling full color 25fps spectrogram was using 2% total CPU, if the task manager is to be believed, on a lowly single-core 2ghz amd64. the same patch on linux has pd and X eaech using like 20% CPU, if top can be believed :/ i'd agree Toxy is pretty nice - its the best youre going to get with the old pd-gui - you get constructors, destructors, all of Tk, and you dont have to know/care how nastily the rest of the GUI is implemented :) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Frank Barknecht wrote: I think, it's comport's fault: [metro] generates clock-delayed messages. These are like messages tagged with a time-stamp referring to Pd's internal clock. However an object needs to actually use the time-stamps and look at the clock to see what time it is. Objects like [vline~] or [delay] do this, but comport doesn't. Well that's interesting! How does one access these timestamps? I thought a bang has no associated info. Or are you referring to a [metro~]? Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: Frank Barknecht wrote: I think, it's comport's fault: [metro] generates clock-delayed messages. These are like messages tagged with a time-stamp referring to Pd's internal clock. However an object needs to actually use the time-stamps and look at the clock to see what time it is. Objects like [vline~] or [delay] do this, but comport doesn't. (Actually I may be wrong here: Maybe comport doesn't need to do anything about this, as it's not a dsp-object. But read on.) Well that's interesting! How does one access these timestamps? I thought a bang has no associated info. Well, there are no real timestamps attached to a bang-message. But Pd has a clock running (actually many, sync'd to the main scheduler clock), and objects that want to know the current time a message arrives, need to look at the clock. vsnapshot~ for example (d_ctl.c) seems to do it like this: In its dsp-perform routine, which is called every sample block, it stores the current time with x-x_time = clock_getlogicaltime(); Then in the bang-routine, vsnapshot~ uses int indx = clock_gettimesince(x-x_time) * x-x_sampspermsec; to calculate the correct index into the incoming sample block from the difference between the time stored previously and the current time. This is what I meant with looking at the clock. Objects like [delay] or [metro] produce these clock-delayed messages. They register their clocks with Pd's main scheduler using clock_new(...) and then order the scheduler to generate the clock-delayed messages like the metro-bangs using clock_delay(). The actual output of [delay], [metro] etc. then is initiated by the scheduler which calls the registered clock methods: delay_tick(), metro_tick(),... However I must admit, I'm not sure how this relates to comport and if comport should also register its port-writing-method with a clock and let the scheduler tick the clock and initiate the writing and if that could get rid of the jitter you mentioned. At least normal objects like [float] don't do any funky clock-stuff and still don't disturb the correct timing of clock-delayed messages. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for PDP testing on Mac OS X
pdp_glx, pd_xv and pdp_sdl all work on linux Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Sounds good. Can someone confirm that pdp_glx works fine on GNU/ Linux? Then I'll make the switch. .hc On May 5, 2007, at 6:25 AM, Luigi Rensinghoff wrote: This is just a tiny little thing. I changed the pdp-examples for OSX. Just so beginners are not irritated. pdp_xv replaced by pdp_glx and little more maybe it would be good to have that changed for OSX-Installers pdp_examples_OSX.zip BYe Luigi___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Patrick Pagano Digital Media Specialist University of Florida Digital Worlds Institute 352-294-2082 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Problem compiling wiimote external
attached is the wiimote compiled with 32 bits intel on ubuntu dapper
downloaded from the author's site
(http://mikewoz.com/index.php?page=pd-stuff)
could we include wiimote on pd extended?
but this external depends on the CWiid library...
pat
- Original Message -
From: Erwan Lerale [EMAIL PROTECTED]
To: Erwan Lerale [EMAIL PROTECTED]
Cc: pd-list@iem.at
Sent: Monday, May 07, 2007 1:39 PM
Subject: Re: [PD] Problem compiling wiimote external
Erwan Lerale wrote:
Hello,
Getting this on gentoo amd64 with gcc 4.1.1:
hi,
Same result with ubuntu 6.10 32 bits... Did anyone managed to compile
this external ?
Cheers
r1
[EMAIL PROTECTED] ~/Desktop/wiimotepd $ make
cc -DPD -O2 -funroll-loops -fomit-frame-pointer -W -Wshadow
-Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch
-I/usr/include -o wiimote.o -c wiimote.c
wiimote.c: In function 'wiimote_doConnect':
wiimote.c:369: error: incompatible type for argument 1 of
'wiimote_connect'
wiimote.c:369: warning: passing argument 2 of 'wiimote_connect' from
incompatible pointer type
The piece of code is here :
[...]
void wiimote_doConnect(t_wiimote *x, t_symbol *addr)
{
unsigned char buf[7];
bdaddr_t bdaddr;
// determine address:
if (addr==gensym(NULL)) bdaddr = (bdaddr_t) *BDADDR_ANY;
else str2ba(addr-s_name, bdaddr);
// connect:
if (g_wiimoteList[0]==NULL) {
x-wiimote = wiimote_connect(bdaddr, wiimote_callback_0);
x-wiimoteID = 0;
g_wiimoteList[0] = x;
}
else if
[...]
Really don't know how to fix that... Anyone can help ?
Thanks a lot
r1
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
wiimote.pd_linux
Description: Binary data
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Connection with sensors - new devices?
Hi Koray~ I am working on a group project that involves Arduino and the parallax PING ultrasonic sensors. Would you be willing to share your Pd patches regarding this usage, as indicated in this email? Thanks in advance! ~Kyle On 12/22/05, Koray Tahiroglu [EMAIL PROTECTED] wrote: hello Hans, I made couple of test patches just to see the range and the stability of the values that I receive from sensors. At the moment, I am testing ultrasound sensor and also self made solar panel board sensor. After this weekend I will begin to construct my final patches for a gig that will be on 14th of January. I can upload the patches on PD site. During our Arduino+PD workshop two weeks ago, we basically started to develop your multi-sensor patch, which actually David had changed couple of things during a previous workshop in Vancouver. All in all i think it is such a nice idea to make easy-to- use framework for sensor boxes. Especially most of the Mac OS X users have problems with comport communication. Koray. - M.Koray Tahiroglu Media Lab, University of Art and Design Helsinki, TaiK Hameentie 135C 00560 Helsinki Finland http://mlab.uiah.fi/~korayt/ http://purenoise.uiah.fi:8000/ tel: +358 40 754 8449 fax: +358 9 75630 555 On Dec 21, 2005, at 9:32 PM, Hans-Christoph Steiner wrote: Do you have an patches that you are willing to share? I want to see how people are using various boards with Pd. I will be working a lot with sensor boards in the coming months, including the Arduino, MultIO, and STEIM's junXionbox. Basically, I want to make an easy-to-use framework like the [hid] toolkit for sensor boxes. So basically, I'll be making high-level abstractions to interface these boxes which output data in a floating point range of 0-1. That means you can then use all of the mapping objects that I wrote for the [hid] toolkit. Actually, I think the grand plan will be to make a separate library of mapping objects, and then librariess for HIDs, sensor boxes, etc. .hc On Dec 20, 2005, at 2:10 PM, Koray Tahiroglu wrote: I've been using arduino with PD heavily since the beginning of December, I am happy with the ready sensor connections as well as self made sensors. And Arduino is an open source microcontroller hardware, http://www.arduino.cc/ cheers, Koray. On Dec 20, 2005, at 7:55 PM, [EMAIL PROTECTED] wrote: There are also the arduino and wiring boards that talk nicely with many progs. - M.Koray Tahiroglu Media Lab, University of Art and Design Helsinki, TaiK Hameentie 135C 00560 Helsinki Finland http://mlab.uiah.fi/~korayt/ http://purenoise.uiah.fi:8000/ tel: +358 40 754 8449 fax: +358 9 75630 555___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list __ __ Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toxy (was Re: [Instance])
Good question, the [widget] and [tot] externals are maybe hacks, but
also very powerfull if the user knows tcl and tk, but with a limited set
of examples, certainly because a few people did try to explore this.
I'm trying to build a 'good old' pianoroll,
http://megalego.free.fr/pd/pianoroll/proll.JPG
with starting from the grid widget available in ix widget extensions,
but it's a quite complicated task for someone that just begin to
understand what is an interpreted language, if anyone is interested into
looking at the code it's attached.
Le lundi 07 mai 2007 à 14:08 -0500, Kyle Klipowicz a écrit :
One question I have with the toxy sliders is this: in the
multiscale-test.pd file, there are some really neat sliders, but how
do you create these, and what are the creation arguments?
I know that we can just go in to the patch as a text file and get this
information, but it would be nice if there were some more instructions
on the usage of these really powerful gui tools. What references are
recommended for experimenting with this?
~Kyle
On 5/7/07, carmen [EMAIL PROTECTED] wrote:
On Mon May 07, 2007 at 01:26:09PM -0500, Kyle Klipowicz wrote:
You are right, I just started looking through the Toxy library
examples, and so far it looks really nice! I'm excited about this! How
do these sliders and such compare with the iemgui objects in terms of
gridlock?
you mean like when the widgets stop updating graphically (numbox moves the
value but doesnt reflect the changes in the GUI) or something else?
it works better than iemgui for effiiency since you can just send over
values, instead of drawing instructions which are often 4x as long.
as long as you stay within the socket bandwidth limit, i found win32 was
the best performer. i mean a scrolling full color 25fps spectrogram was
using 2% total CPU, if the task manager is to be believed, on a lowly
single-core 2ghz amd64. the same patch on linux has pd and X eaech using
like 20% CPU, if top can be believed :/
i'd agree Toxy is pretty nice - its the best youre going to get with the
old pd-gui - you get constructors, destructors, all of Tk, and you dont
have to know/care how nastily the rest of the GUI is implemented :)
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
namespace eval ::xt {
proc proll_clic {w k t div scx scy} {
zoom $w $k $t $scx $scy
bind $w Motion ::xt::draw $w $t %x %y $div motion 0 item
bind $w 1 ::xt::draw $w $t %x %y $div draw 0 item
}
proc draw {w t x y div type i item} {
if {$i == 0} {
set x [$w canvasx $x]
set y [$w canvasy $y]
}
for {set z 0} {$z = [expr $div - 1]} {incr z} {
set j [expr $z + 1]
if {$z 1} {
set rectx1 0
set rectx2 [lindex [$w coords gridver1] 0]
set q $z
}
if {$z 0} {
set x1 [lindex [$w coords gridver$z] 0]
set x2 [lindex [$w coords gridver$j] 0]
if {$x1 = $x $x =$x2} {
set rectx1 $x1
set rectx2 $x2
set q $z
}
}
}
for {set i 0} {$i = 127} {incr i} {
set j [expr $i + 1]
if {$i 1} {
set recty1 0
set recty2 [lindex [$w coords gridhor1] 1]
set o 0
}
if {$i 0} {
set y1 [lindex [$w coords gridhor$i] 1]
set y2 [lindex [$w coords gridhor$j] 1]
if {$y1 = $y $y =$y2} {
set recty1 $y1
set recty2 $y2
set o [expr abs(-1*($i-127))]
}
}
}
switch -- $type {
draw {
if {[$w find withtag note$rectx1$rectx2] == } {
pd $t.rp _cb add $q $o 127 500;
proll_draw $w $t draw $rectx1 $rectx2 $recty1 $recty2 $div}}
redraw {
$w delete $item
proll_draw $w $t draw $rectx1 $rectx2 $recty1 $recty2 $div
}
delete {
pd $t.rp _cb delete $q $o;
$w delete $item
}
motion {proll_draw $w $t $type $rectx1 0 $recty1 0 $div}
}
}
proc proll_draw {w t type x1 x2 y1 y2 d} {
set x1 [expr $x1+1];set x2 [expr $x2-1];set y1 [expr $y1+1];set y2
[expr $y2-1]
switch -- $type {
draw {
$w create rectangle $x1 $y1 $x2 $y2 -fill red -tags note$x1$y1
-activefill yellow -disabledfill black
#
