Re: [PD] small polyWaveSynth issue; udpdate available
Hallo, Phil Stone hat gesagt: // Phil Stone wrote: From what I can tell, this happens when DSP is already running, and the wave tables, which are wrapped in Frank's loadbang-firing-[singleton], are not initialized (or at least not finished initializing) before the [tabread~] oscillators start. The original patch had the singleton object way down in the patch file, which made the error message occurrence more likely. (As an aside: is there a best-practice that completely avoids this sort of load-order issue?) In the end it may not be possible to completely avoid this. I think, in your synth what you could do is wait for the singleton to finish creating, then switch on the tabreads e.g. using [switch~]. The table-singleton should be finished as soon as you get a non-zero value out of one of its outlets. Though maybe this approach wouldn't work in your case. Another thing to check could be the value of the internal [value ...] counter in singleton. It's global and you know its name, IIRC. Which reminds me of another issue in your synth: You are creating a lot of global sends and receives with it by using [r $1-something] all over. I think it is possible to change most of these to [r $0-something] and effectively hide them from the world outside of polyWaveSynth.pd This would lower the risk of accidentally reusing one of these names in another abstraction (whose author may be somebody else). 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] installing flext
Thomas Grill wrote: bash build.sh pd clean bash build.sh pd sudo bash build.sh pd install well it seems it should be: bash build.sh pd gcc # edit buildsys/config-lnx-pd-gcc.txt bash build.sh pd gcc # edit config.txt bash build.sh pd gcc sudo bash build.sh pd gcc install Logical when you know... -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing flext
Am 08.09.2007 um 17:05 schrieb Atte André Jensen: Thomas Grill wrote: bash build.sh pd clean bash build.sh pd sudo bash build.sh pd install well it seems it should be: bash build.sh pd gcc # edit buildsys/config-lnx-pd-gcc.txt bash build.sh pd gcc # edit config.txt bash build.sh pd gcc sudo bash build.sh pd gcc install Logical when you know... That's what it tells you to do when you run it. You can also edit the two config files beforehand, and build afterwards. greetings, Thomas ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small polyWaveSynth issue; udpdate available
Hi Frank, The [r $1-something] receives are exposed to the outside by design, so that all parameters can be controlled programatically and not just by the sliders and controls of the UI. They also permit multiple synthesizers to be separately addressable. Finally, $1 serves as the prefix for [sssad], so that multiple [polyWaveSynth]s can have their state saved or restored simultaneously. In my current setup, I use two [polyWaveSynth]s, and all my presets contain values for both synthesizers. If one chooses $1 wisely, for instance wav1, the likelihood of name collisions is not great, I think, as the resulting receives look like wav1-atk or wav1-freq. I understand what you're saying about conservation of namespace, though, and I did try to use $0- whenever possible, like in the [polyWaveVoice~] patch. Thanks for writing, Phil Frank Barknecht wrote: Which reminds me of another issue in your synth: You are creating a lot of global sends and receives with it by using [r $1-something] all over. I think it is possible to change most of these to [r $0-something] and effectively hide them from the world outside of polyWaveSynth.pd This would lower the risk of accidentally reusing one of these names in another abstraction (whose author may be somebody else). Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] ask for cvs access
federico wrote: hola, hey! externs I'm going to commit: grid: a gui 2d grid editor made esecially for editing/sequencing lists of floats, it should be a nice frontend for iemmatrix (I'm planning to add iemmatrix-specific messages, so that is more straightforward) notehigh/notelow: externals for getting monophonic midi from [midiin] err, have you ever seen that page? http://ydegoyon.free.fr/software.html ? ehm... of course I've seen that... I've borrowed your tk2c script too ;) grid will create other name conflicts again, if not duplicate funcionalities we have namespace prefixes for that, no? i don't trust namespaces and that everybody knows how to use it correctly so better to avoid name conflicts before the damage's done. anyway I'll think to a more self-explicative name... editmatrix seems a good candidate... oh yeh, is see what it is now, good idea and kind of useful for making a good old fast tracker patch, ain't it? can i suggest the name of 'tracker' ? just to keep it simple and clear. saludos, sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small polyWaveSynth issue; udpdate available
Sorry to be so rude as to reply to my own message, but I have thought more about Frank's original message since my first reply. I am beginning to see that it might not be a good idea to expose all those receives, even if the likelihood of name-collision is small. If all patches were designed this way, there would be a great many possible collisions, so the likelihood would increase, even with careful naming. It would be difficult to track down, too. The more I think about it, this should be an anti-pattern for PD. It is very tempting to do things this way because PD send/receives are a convenient and clean way to map a large number of parameters. I have been thinking about an alternative anyway, which is for [polyWaveSynth] to have one message inlet which accepts OSC-format messages, parses them with OSCroute and sends them to the appropriate targets. It's slightly less efficient, but much more encapsulated, and suggests some interesting new capabilities, too... Phil Stone wrote: Hi Frank, The [r $1-something] receives are exposed to the outside by design, so that all parameters can be controlled programatically and not just by the sliders and controls of the UI. They also permit multiple synthesizers to be separately addressable. Finally, $1 serves as the prefix for [sssad], so that multiple [polyWaveSynth]s can have their state saved or restored simultaneously. In my current setup, I use two [polyWaveSynth]s, and all my presets contain values for both synthesizers. If one chooses $1 wisely, for instance wav1, the likelihood of name collisions is not great, I think, as the resulting receives look like wav1-atk or wav1-freq. I understand what you're saying about conservation of namespace, though, and I did try to use $0- whenever possible, like in the [polyWaveVoice~] patch. Thanks for writing, Phil Frank Barknecht wrote: Which reminds me of another issue in your synth: You are creating a lot of global sends and receives with it by using [r $1-something] all over. I think it is possible to change most of these to [r $0-something] and effectively hide them from the world outside of polyWaveSynth.pd This would lower the risk of accidentally reusing one of these names in another abstraction (whose author may be somebody else). Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [Pd] Building OSCx on 64-bit Debian
Hi. I acquired a p5 glove, and the Pd interface I found for it relies on OSCx. I've been trying to build it, having added -fPIC to it, but I get this: make[1]: Entering directory `/home/chuckk/Glove/pd/externals/OSCx/src' cc -Wl,-export_dynamic -shared -o sendOSC.pd_linux sendOSC.o htmsocket.o OSC-system-dependent.o -L../../../pd/bin -lpd -lc -lm ../libOSC/libOSC.a /usr/bin/ld: cannot find -lpd collect2: ld returned 1 exit status make[1]: *** [sendOSC.pd_linux] Error 1 make[1]: Leaving directory `/home/chuckk/Glove/pd/externals/OSCx/src' make: *** [all] Error 2 I added several paths to the INCLUDES line in src/Makefile, as the guy suggested, with the path to a Pd src folder, but still it can't find this -lpd. I read man ld and tried searching for any kind of *libpd*, *pd.a*, or *pd.so* on my entire hard drive, and none of them exist. Should I replace this -lpd with something else? I tried removing it, and it built a faulty set of OSCx objects that don't work. Thanks. -Chuckk -- http://www.badmuthahubbard.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] polyWaveSynth issue
Hi pdlers i was curious to check out that synth, but i get this error. the screenshot i from ubuntu, but it was the same on OS X. Bild 3.png Description: application/applefile inline: Bild 3.png i am sure you know the trick, thanks luigi___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Pd] Building OSCx on 64-bit Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Sep 08, 2007 at 06:48:52PM -0400, Chuckk Hubbard wrote: Hi. I acquired a p5 glove, and the Pd interface I found for it relies on OSCx. I've been trying to build it, having added -fPIC to it, but I get this: make[1]: Entering directory `/home/chuckk/Glove/pd/externals/OSCx/src' cc -Wl,-export_dynamic -shared -o sendOSC.pd_linux sendOSC.o htmsocket.o OSC-system-dependent.o -L../../../pd/bin -lpd -lc -lm ../libOSC/libOSC.a /usr/bin/ld: cannot find -lpd collect2: ld returned 1 exit status make[1]: *** [sendOSC.pd_linux] Error 1 make[1]: Leaving directory `/home/chuckk/Glove/pd/externals/OSCx/src' make: *** [all] Error 2 I added several paths to the INCLUDES line in src/Makefile, as the guy suggested, with the path to a Pd src folder, but still it can't find this -lpd. I read man ld and tried searching for any kind of *libpd*, *pd.a*, or *pd.so* on my entire hard drive, and none of them exist. Should I replace this -lpd with something else? I tried removing it, and it built a faulty set of OSCx objects that don't work. The linker uses -L not -I to determine its paths. Try -L/usr/wherever/pd/libs/are/located ? - -ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG40Iwe8HF+6xeOIcRAod2AKDtPy6HN+RA7YwsdbkK/AMyEjGErgCgtRyu pEPOATDtCGx6A31QzKXIGPY= =kE7A -END PGP SIGNATURE- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A system to read individual pixels from an image
Merhaba Batuhan, To my knowledge, there are ways to do that in GEM. - Loading images to see them in a window comes in pretty easy. Just use the [pix_image] and/or [pix_multiimage} to actually load the stuff (I personnaly use the tiff format for uncompressed images). Then use [pix_texture] to apply them to a basic GL shape like [rectangle] or [square] depending on the aspect ratio of the picture. Building a subpatch/abstraction that detects this ratio and adapts the rectangle size accordingly shouldn't be very complicated, I have an abstraction hanging around that I could give you if you wish. - Getting pixel color can apparently be done with [pix_data]. See help file, never used it yet... - [gemmouse] is your friend to get mouse coordinates and button information from inside the gemwin. ++ Jé Batuhan Bozkurt a écrit : Hello, I'm mostly using the audio capabilities of PD and now I need this functionality to port my image synthesizer I've made in Max/MSP before(which was a pain while building because of the audiorate rounding errors in Max/MSP) to PD. I was using the LCD object in there. The functionality I need is: * I want to be able to read images into a window to see its contents(being able to load uncompressed images are enough) * A message like getpixel x y should return me the RGB values of that pixel * It would be nice to be able to draw single pixels with mouse at least...(can be implemented with something like setpixel x y r g b I know that people are doing fancy stuff with GEM and other libraries but I really don't know what to chase for this simple task. Thanks in advance Batuhan ___ 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] polyWaveSynth issue
Hi Luigi, This is a happening in [polypoly] where it replicates the [polyWaveVoice~] objects. I can't figure out what the problem is just from a screen shot, though. Did you get all the dependencies? It looks like you have at least some of the polypoly objects, but something like this is often a path problem: all the dependencies, as well as the polyWaveSynth archive, have to be in PD's path. Sorry if I'm suggesting obvious things to you, but I can't think what else this would be. Anyone else having the same trouble? Phil Luigi Rensinghoff wrote: Hi pdlers i was curious to check out that synth, but i get this error. the screenshot i from ubuntu, but it was the same on OS X. i am sure you know the trick, thanks luigi ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Rotary controllers in PD?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My MIDI controller is an M-Audio Axiom 49. It has 8 rotary controllers which can output continuous controller messages. This may be my way out of the 4-bit hole, and allow me to control parameters in PD with finer than 128 discreet steps. Are there any externals or internals in PD to handle these things? The Axiom manual states that each rotary controller can be configured in one of these ways: 2's complement from 64/Relative (Binary Offset) 2's Complement from 0 / relative (2's Complement) Sign Magnitude / Relative (Signed Bit) Sign Magnitude / Relative (Signed Bit 2) Single Value Increment/Decrement RPN Increment/Decrement Message NRPN Increment/Decrement Message I tried each of these and peeked at the MIDI stream to see what they do, and also at the output of PD's ctlin to see what might emerge. The sign magnitude and 2's complement ones look pretty promising: they indicate which direction (up/down) and how fast you spin the thing. Now, to turn those numbers into a float between -1 and 0 that I can use for controlling various parameters in PD. However, I'm getting old and lazy. I'm convinced that *someone* must have already solved this problem, and created an abstraction for using rotary controllers in PD. Google turned up hours worth of fascinating clicking, having nothing to do with what I was looking for. So if anyone can point me to an example patch or docs for using rotary controllers in any of the above formats, in PD,, please let me know. - -ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG41SRe8HF+6xeOIcRAt2QAKDMF0MxlYPFrstiXI+glQVKfHiLawCg5PIc yR+zUNDl2UfVDwh35R3YBRw= =z2Am -END PGP SIGNATURE- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A system to read individual pixels from an image
Jerome Tuncer wrote: Merhaba Batuhan, To my knowledge, there are ways to do that in GEM. - Loading images to see them in a window comes in pretty easy. Just use the [pix_image] and/or [pix_multiimage} to actually load the stuff (I personnaly use the tiff format for uncompressed images). Then use [pix_texture] to apply them to a basic GL shape like [rectangle] or [square] depending on the aspect ratio of the picture. Building a subpatch/abstraction that detects this ratio and adapts the rectangle size accordingly shouldn't be very complicated, I have an abstraction hanging around that I could give you if you wish. - Getting pixel color can apparently be done with [pix_data]. See help file, never used it yet... - [gemmouse] is your friend to get mouse coordinates and button information from inside the gemwin. ++ Thanks Jerome, this was the info I was looking for! Batuhan ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
