Hello everybody,
There is a load-order issue in [polyWaveSynth] (the synthesizer abstraction I announced here the other day) that may cause minor irritation -- it is nothing serious, the worst that will happen is that some error messages like this may sully your console during initialization:
error tabread~: te_sine: no such array
...the synthesizer works perfectly fine after this, and there are no harmful side-effects -- but it's a bit annoying.
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?)
To minimize the possibility of this happening, I've edited [polyWaveSynth] so that the wave tables are loaded and initialized as early as possible (I did this by selecting all the objects in [polyWaveSynth] with cmd-A, then I de-selected the [lb_singleton ETABLES erbeTables] object; finally I did a cut-paste - this makes the [lb-singleton ...] object be the first object loaded). If you want to be absolutely sure it doesn't happen, don't switch on DSP until after [polyWaveSynth] is completely loaded, but it shouldn't be necessary to worry about this.
The updated patch is available in its archive here:
http://www.pkstonemusic.com/code/polyWaveSynth.tgz . I've also attached
polyWaveSynth.pd which is the only diff, so you don't need to get the
whole archive if you already have it.
(web page for polyWaveSynth: http://www.pkstonemusic.com/polyWaveSynth.html -- hey, is *anybody* using this? I see it being downloaded, but I haven't heard any feedback, except from Frank -- is it even working for anybody else??? )
Phil Stone pkstonemusic.com
#N canvas 262 22 719 672 10; #X obj 2 557 lb_singleton ETABLES erbeTables; #X obj 6 31 cnv 15 74 67 empty empty empty 20 12 0 14 -187454 -66577 0; #X obj 8 31 vradio 11 1 1 6 $1-cWavetype $1-r-cWavetype carrier 0 -6 0 8 -355 -241291 -1 1; #X text 22 28 sine; #X text 21 39 square; #X text 21 50 ramp; #X text 21 61 pulse; #X text 20 73 triangle; #X obj 45 209 vsl 10 40 1 5000 0 1 $1-rel $1-r-rel R 4 48 0 8 -258113 -1 -1 501 1; #X obj 6 209 vsl 10 40 1 5000 0 1 $1-atk $1-r-atk A 4 48 0 8 -258113 -1 -1 8 1; #X obj 9 159 hsl 128 15 0 1 0 1 $1-modAmp $1-r-modAmp modAmp 4 9 0 8 -190976 -1 -1 0 0; #X obj 9 141 hsl 128 15 0 1 0 1 $0-modFreqFrac $0-r-modFreqFrac modFreq 4 9 0 8 -195008 -1 -1 0 1; #X obj 9 121 hsl 128 15 0 2 0 1 $1-fltQ $1-r-fltQ Q 4 9 0 8 -138752 -1 -1 2100 1; #X obj 9 103 hsl 128 15 1 10000 1 1 $1-fltFreq $1-r-fltFreq filter_freq. 4 9 0 8 -138752 -1 -1 11581 0; #X text 21 84 noise; #X floatatom 147 104 6 0 0 0 - #1-fltFreq -; #X floatatom 147 122 5 0 0 0 - #1-fltQ -; #X obj 140 456 random 100; #X obj 140 477 / 100; #X obj 260 245 r $1-amp; #X obj 346 283 r $1-rel; #X obj 227 612 outlet~; #X obj 435 611 outlet~; #X obj 227 295 pack f f; #X obj 346 263 r $1-sus; #X obj 346 242 r $1-dec; #X obj 32 209 vsl 10 40 0 100 0 1 $1-sus $1-r-sus S 4 48 0 8 -258113 -1 -1 2800 1; #X obj 19 209 vsl 10 40 1 9999 0 1 $1-dec $1-r-dec D 4 48 0 8 -258113 -1 -1 1100 1; #X obj 336 194 r $1-atk; #X obj 140 413 spigot; #X obj 151 199 nbx 4 14 2 9999 0 1 $1-panPorta $1-r-panPorta pan_rate 0 -6 0 10 -204786 -1 -1 1700 256; #X obj 395 397 bng 15 250 50 0 $0-reset empty reset 18 4 0 8 -262144 -1 -1; #X obj 395 421 f $2; #X obj 227 164 r $1-freq; #X text 394 157 $1 prefix for params.; #X text 394 172 $2 number of voices; #X msg 395 443 $1 polyWaveVoice~; #X obj 336 221 f; #X obj 227 189 t f b b; #X obj 91 31 cnv 15 74 67 empty empty empty 20 12 0 14 -187454 -66577 0; #X obj 93 31 vradio 11 1 1 6 $1-mWavetype $1-r-mWavetype modulator 0 -6 0 8 -355 -241291 -1 0; #X text 107 28 sine; #X text 106 39 square; #X text 106 50 ramp; #X text 106 61 pulse; #X text 105 73 triangle; #X text 106 84 noise; #X obj 176 31 vsl 15 64 1e-05 24 1 1 $1-gain $1-r-gain gain 0 -8 0 8 -35665 -1 -1 4326 1; #X obj 227 584 *~; #X obj 435 584 *~; #X obj 6 189 nbx 1 14 0 9 0 1 $1-envExp $1-r-envExp curve 21 6 0 10 -261630 -1 -1 2 256; #X obj 103 209 vsl 10 40 1 5000 0 1 $1-fltRel $1-r-fltRel R 4 48 0 8 -258113 -1 -1 600 1; #X obj 64 209 vsl 10 40 1 5000 0 1 $1-fltAtk $1-r-fltAtk A 4 48 0 8 -258113 -1 -1 8 1; #X obj 90 209 vsl 10 40 0 100 0 1 $1-fltSus $1-r-fltSus S 4 48 0 8 -258113 -1 -1 1200 1; #X obj 77 209 vsl 10 40 1 9999 0 1 $1-fltDec $1-r-fltDec D 4 48 0 8 -258113 -1 -1 600 1; #X obj 64 189 nbx 1 14 0 9 0 1 $1-fltEnvExp $1-r-fltEnvExp curve 21 6 0 10 -261630 -1 -1 0 256; #X text 5 173 amp. env.; #X text 65 173 filter env.; #X obj 509 253 r $1-modFreq; #X obj 422 299 r $1-fltFreq; #X obj 422 320 r $1-fltQ; #X obj 590 254 r $1-panPorta; #X obj 509 233 r $1-modAmp; #X obj 509 213 r $1-mWavetype; #X obj 347 303 r $1-envExp; #X obj 419 194 r $1-fltAtk; #X obj 420 215 r $1-fltDec; #X obj 420 236 r $1-fltSus; #X obj 421 257 r $1-fltRel; #X obj 421 278 r $1-fltEnvExp; #X obj 148 159 tgl 15 1 $1-ratio $1-r-ratio ratio 18 6 0 10 -190976 -1 -1 1 1; #X obj 523 274 r $1-ratio; #X obj 137 261 nbx 5 14 -9999 9999 0 1 $1-detune $1-r-detune detune 0 -6 0 10 -232576 -1 -1 0 256; #X floatatom 147 142 6 0 0 0 - #1-modFreq -; #X floatatom 35 265 5 0 0 1 lastKnob - -; #X obj 137 208 vradio 10 1 1 2 $1-panMode $1-r-panMode empty 0 -6 0 10 -204786 -1 -1 1; #X obj 69 310 r $1-panMode; #X obj 2 382 spigot; #X obj 151 382 == 0; #X obj 41 450 f 0.5; #X obj 153 226 hsl 40 15 0 1 0 1 $1-panPos $1-r-panPos position -2 -6 0 10 -204786 -1 -1 1950 1; #X obj 2 504 s $1-panPorta; #X obj 140 434 b; #X obj 2 405 t b b; #X obj 69 335 t f f; #X msg 2 481 0; #X text 81 289 Panning; #X obj 315 526 pack 0 50; #X obj 315 550 vline~; #X obj 315 502 r $1-gain; #X text 5 358 fixed; #X text 154 363 random; #X obj 237 224 s $0-setpan; #X obj 120 335 r $0-setpan; #X obj 338 367 pack f f f f f f f f f f f f f f f f f f f f; #X obj 591 275 r $1-detune; #X obj 590 234 r $1-position; #X obj 101 504 s $1-position; #X obj 44 405 r $1-panPos; #X obj 235 398 r global-release; #X obj 227 476 polypoly $2 1 polyWaveVoice~ global; #X msg 235 441 clear; #X text 116 203 rnd; #X text 116 215 fix; #X text 313 92 Two global (affecting all voices simultaneously) parameters are implemented: global-pbend (pitchbend in cents) and global-release (use for "All Notes Off").; #X obj 207 143 inlet freq; #X obj 272 267 inlet amp; #N canvas 386 102 772 550 sssadStuff 0; #X obj 289 273 s $1-r-fltFreq; #X obj 289 225 r $1-fltFreq; #X obj 289 297 r $1-fltQ; #X obj 289 345 s $1-r-fltQ; #X obj 12 4 r $1-atk; #X obj 13 53 s $1-r-atk; #X obj 436 242 r $1-modFreq; #X obj 436 296 s $1-r-modFreq; #X obj 405 338 r $1-modAmp; #X obj 405 386 s $1-r-modAmp; #X obj 14 223 r $1-rel; #X obj 14 271 s $1-r-rel; #X obj 13 76 r $1-dec; #X obj 13 125 s $1-r-dec; #X obj 13 148 r $1-sus; #X obj 14 195 s $1-r-sus; #X obj 289 249 sssad $1/filtFreq; #X obj 289 321 sssad $1/filtQ; #X obj 436 266 sssad $1/modFreq; #X obj 405 362 sssad $1/modAmpl; #X obj 13 29 sssad $1/attack; #X obj 13 101 sssad $1/decay; #X obj 14 171 sssad $1/sustain; #X obj 14 247 sssad $1/release; #X obj 330 78 r $1-mWavetype; #X obj 331 103 sssad $1/mWaveType; #X obj 331 127 s $1-r-mWavetype; #X obj 504 31 r $1-gain; #X obj 505 56 sssad $1/gain; #X obj 505 80 s $1-r-gain; #X obj 15 346 s $1-r-envExp; #X obj 15 322 sssad $1/envExp; #X obj 14 297 r $1-envExp; #X obj 152 4 r $1-fltAtk; #X obj 153 29 sssad $1/filtAttack; #X obj 153 53 s $1-r-fltAtk; #X obj 153 76 r $1-fltDec; #X obj 153 125 s $1-r-fltDec; #X obj 153 101 sssad $1/filtDecay; #X obj 154 171 sssad $1/filtSustain; #X obj 154 247 sssad $1/filtRelease; #X obj 155 322 sssad $1/filtEnvExp; #X obj 153 148 r $1-fltSus; #X obj 154 195 s $1-r-fltSus; #X obj 154 223 r $1-fltRel; #X obj 154 271 s $1-r-fltRel; #X obj 154 297 r $1-fltEnvExp; #X obj 155 346 s $1-r-fltEnvExp; #X obj 547 242 r $1-ratio; #X obj 547 266 sssad $1/ratioMod; #X obj 547 295 s $1-r-ratio; #X obj 274 513 s $1-modFreq; #X obj 274 452 r $0-modFreqFrac; #X obj 383 458 r $1-ratio; #X obj 531 488 s $0-r-modFreqFrac; #X obj 531 425 r $1-r-modFreq; #X obj 640 431 r $1-r-ratio; #N canvas 946 145 306 314 modFreqOrRatioToSlider 0; #X obj 145 115 == 0; #X obj 143 166 spigot 0; #X obj 145 7 inlet ratioOn; #X text 23 210 freq. is 'free'; #X obj 16 261 outlet; #X obj 16 192 / 4000; #X obj 16 169 spigot 0; #X text 108 226 freq. is ratio of carrier; #X obj 15 7 inlet modSaved; #X obj 16 47 t f f; #X obj 143 191 / 16; #X obj 145 46 t f f; #X connect 0 0 6 1; #X connect 1 0 10 0; #X connect 2 0 11 0; #X connect 5 0 4 0; #X connect 6 0 5 0; #X connect 8 0 9 0; #X connect 9 0 6 0; #X connect 9 1 1 0; #X connect 10 0 4 0; #X connect 11 0 0 0; #X connect 11 1 1 1; #X restore 531 456 pd modFreqOrRatioToSlider; #N canvas 358 204 281 222 sliderToModFreqOrRatio 0; #X obj 133 58 == 0; #X obj 10 123 * 4000; #X obj 118 100 spigot 0; #X obj 10 100 spigot 1; #X obj 133 4 inlet ratioOn; #X text 103 170 freq. is ratio of carrier; #X text 22 142 freq. is 'free'; #X obj 148 146 int; #X obj 31 178 outlet; #X obj 9 4 inlet modFreqFrac; #X obj 148 123 * 16; #X obj 133 27 t f f; #X connect 0 0 3 1; #X connect 1 0 8 0; #X connect 2 0 10 0; #X connect 3 0 1 0; #X connect 4 0 11 0; #X connect 7 0 8 0; #X connect 9 0 3 0; #X connect 9 0 2 0; #X connect 10 0 7 0; #X connect 11 0 0 0; #X connect 11 1 2 1; #X restore 274 483 pd sliderToModFreqOrRatio; #X text 278 416 Convert slider (0.0 - 1.0) to freq. ,; #X text 279 431 either a ratio , or a literal freq. value; #X text 529 404 to slider value (0.0 - 1.0); #X text 527 389 Convert saved freq. (ratio or absolute); #X obj 9 392 r $1-panPos; #X obj 9 440 s $1-r-panPos; #X obj 9 416 sssad $1/panPosition; #X obj 8 469 r $1-panMode; #X obj 8 493 sssad $1/panMode; #X obj 8 517 s $1-r-panMode; #X obj 136 392 r $1-panPorta; #X obj 136 416 sssad $1/panPortamento; #X obj 136 440 s $1-r-panPorta; #X obj 135 469 r $1-detune; #X obj 135 493 sssad $1/detune; #X obj 135 517 s $1-r-detune; #X text 392 151 Because of the way modFreq is overloaded , the ratio switch must be set before modFreq changes , therefore it has to occur later in this subpatch - so don't change the order of these objects if you can help it (or if you do , make sure the ratio stuff ends up later in the patch file than modFreq -- sorry I can't think of a less kludgey way to do this):; #X obj 329 5 r $1-cWavetype; #X obj 329 30 sssad $1/cWaveType; #X obj 329 54 s $1-r-cWavetype; #X connect 1 0 16 1; #X connect 2 0 17 1; #X connect 4 0 20 1; #X connect 6 0 18 1; #X connect 8 0 19 1; #X connect 10 0 23 1; #X connect 12 0 21 1; #X connect 14 0 22 1; #X connect 16 0 0 0; #X connect 17 0 3 0; #X connect 18 0 7 0; #X connect 19 0 9 0; #X connect 20 0 5 0; #X connect 21 0 13 0; #X connect 22 0 15 0; #X connect 23 0 11 0; #X connect 24 0 25 1; #X connect 25 0 26 0; #X connect 27 0 28 1; #X connect 28 0 29 0; #X connect 31 0 30 0; #X connect 32 0 31 1; #X connect 33 0 34 1; #X connect 34 0 35 0; #X connect 36 0 38 1; #X connect 38 0 37 0; #X connect 39 0 43 0; #X connect 40 0 45 0; #X connect 41 0 47 0; #X connect 42 0 39 1; #X connect 44 0 40 1; #X connect 46 0 41 1; #X connect 48 0 49 1; #X connect 49 0 50 0; #X connect 52 0 58 0; #X connect 53 0 58 1; #X connect 55 0 57 0; #X connect 56 0 57 1; #X connect 57 0 54 0; #X connect 58 0 51 0; #X connect 63 0 65 1; #X connect 65 0 64 0; #X connect 66 0 67 1; #X connect 67 0 68 0; #X connect 69 0 70 1; #X connect 70 0 71 0; #X connect 72 0 73 1; #X connect 73 0 74 0; #X connect 76 0 77 1; #X connect 77 0 78 0; #X restore 507 508 pd sssadStuff; #X text 340 40 s mySynth-atk1 20; #X text 315 12 Messages are sent to these parameters -- from UI controls by default , but potentially , directly , as in:; #X text 313 57 Note that they will only be sent to [polyWaveVoice~]s on the next attack.; #X obj 509 193 r $1-cWavetype; #X text 462 548 Phil Stone - http://pkstonemusic.com; #X connect 8 0 74 0; #X connect 9 0 74 0; #X connect 17 0 18 0; #X connect 18 0 97 0; #X connect 19 0 23 1; #X connect 20 0 94 3; #X connect 23 0 100 0; #X connect 24 0 94 2; #X connect 25 0 94 1; #X connect 26 0 74 0; #X connect 27 0 74 0; #X connect 28 0 37 1; #X connect 29 0 82 0; #X connect 31 0 32 0; #X connect 31 0 101 0; #X connect 32 0 36 0; #X connect 33 0 38 0; #X connect 36 0 100 2; #X connect 37 0 94 0; #X connect 38 0 23 0; #X connect 38 1 37 0; #X connect 38 2 92 0; #X connect 48 0 21 0; #X connect 49 0 22 0; #X connect 51 0 74 0; #X connect 52 0 74 0; #X connect 53 0 74 0; #X connect 54 0 74 0; #X connect 58 0 94 15; #X connect 59 0 94 10; #X connect 60 0 94 11; #X connect 61 0 94 18; #X connect 62 0 94 14; #X connect 63 0 94 13; #X connect 64 0 94 4; #X connect 65 0 94 5; #X connect 66 0 94 6; #X connect 67 0 94 7; #X connect 68 0 94 8; #X connect 69 0 94 9; #X connect 71 0 94 16; #X connect 76 0 84 0; #X connect 77 0 83 0; #X connect 78 0 29 1; #X connect 79 0 97 0; #X connect 82 0 17 0; #X connect 83 0 79 0; #X connect 83 1 85 0; #X connect 84 0 77 1; #X connect 84 1 78 0; #X connect 85 0 81 0; #X connect 87 0 88 0; #X connect 88 0 48 1; #X connect 88 0 49 1; #X connect 89 0 87 0; #X connect 93 0 29 0; #X connect 93 0 77 0; #X connect 94 0 100 1; #X connect 95 0 94 19; #X connect 96 0 94 17; #X connect 98 0 79 1; #X connect 99 0 101 0; #X connect 100 0 48 0; #X connect 100 1 49 0; #X connect 101 0 100 0; #X connect 105 0 38 0; #X connect 106 0 23 1; #X connect 111 0 94 12; #X coords 0 -1 1 1 200 286 1 0 0;
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__
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
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
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
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
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote:
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.
You can fix this by adding your polyWaveSynth directory to your pd-path or copy over poly*.pd to that director.y As polypoly.pd lives in a different directory from polyWaveSynth, it cannot find the objects it creates dynamically. (I'm not sure, if it *should* see them, though, i.e. if this is a bug in Pd.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Phil~
Perhaps you could repackage the polyWaveSynth with the required abstractions included, since they are very small in size to make much of a difference? This might eliminate much of the frustration that seems to be plaguing some people.
~Kyle
On 9/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote:
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.
You can fix this by adding your polyWaveSynth directory to your pd-path or copy over poly*.pd to that director.y As polypoly.pd lives in a different directory from polyWaveSynth, it cannot find the objects it creates dynamically. (I'm not sure, if it *should* see them, though, i.e. if this is a bug in Pd.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Kyle,
I thought of doing that, but reconsidered because it seems like it might lead to versioning problems, namespace clashes, multiple copies of objects and possibly, dogs and cats sleeping together.
Or am I over-thinking it?
Phil
Kyle Klipowicz wrote:
Hi Phil~
Perhaps you could repackage the polyWaveSynth with the required abstractions included, since they are very small in size to make much of a difference? This might eliminate much of the frustration that seems to be plaguing some people.
~Kyle
On 9/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote:
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.
You can fix this by adding your polyWaveSynth directory to your pd-path or copy over poly*.pd to that director.y As polypoly.pd lives in a different directory from polyWaveSynth, it cannot find the objects it creates dynamically. (I'm not sure, if it *should* see them, though, i.e. if this is a bug in Pd.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
I thought of doing that, but reconsidered because it seems like it might lead to versioning problems, namespace clashes, multiple copies of objects and possibly, dogs and cats sleeping together.
I've found an easier solution: add [declare -path .] to polyWaveSynth.pd. Or was it PolyWaveSynth.pd? PolyWavesynth.pd? I think all lowercase names are easier to remember <hint,hint>. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
I thought of doing that, but reconsidered because it seems like it might lead to versioning problems, namespace clashes, multiple copies of objects and possibly, dogs and cats sleeping together.
I've found an easier solution: add [declare -path .] to polyWaveSynth.pd.
That requires > 40.0, right? Also, there doesn't seem to be a help patch for [declare] -- I've seen it mentioned here on the list, but is it documented anywhere? It looks like it would add [polyWaveSynth]s folder to PD's path -- but how would PD find [polyWaveSynth] to load it in the first place?
Plus, does this really avoid any problems from including dependent objects (possibly creating multiple copies) inside abstraction folders?
Or was it PolyWaveSynth.pd? PolyWavesynth.pd? I think all lowercase names are easier to remember <hint,hint>. ;)
i'llconsiderthatforthenextrelease. :-)
Phil
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
That requires > 40.0, right? Also, there doesn't seem to be a help patch for [declare] -- I've seen it mentioned here on the list, but is it documented anywhere? It looks like it would add [polyWaveSynth]s folder to PD's path -- but how would PD find [polyWaveSynth] to load it in the first place?
Uhm, I don't really know, when declare was introduced, may indeed be with 0.40.
Anyway, adding the directory of pWS to the path will make polypoly.pd find the objects it needs to create copies from. One can either add the directory using "pd -path ..." or using [declare]. However there are still some problems with that, which I will post in a separate mail.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Phil~
I don't think it would cause problems if you keep them in a subdirectory and addressed the abstractions with abs/foobar.pd type naming. Does Pd search the patch's folder first for all non-native objects before parsing the path? Also, this will all become resolved once Pd-extended moves forward to including more recent abstractions in its releases (i.e. Pd-extended-0.40 or however it will be branded).
Until then, we just can't really expect the same crowd that Pd-extended is marketed for to know much about cvs and setting up the paths and stuff. It's better to take the high road and avoid elitist isolationism and make things easy as possible for new users to dive into: Pd needs adherents to thrive and become a serious competitor of similar commercial options.
I think that this object will be a great selling point for new Pd users, especially because of the polyphony. Polyphony management is one of the most annoying things for new (and more seasoned) users to deal with in Pd. Your synth (combined w/ Frank's freaking awesome abstractions) has a great possibility for becoming a template for many awesome modifications and enhancements down the line.
~Kyle
On 9/9/07, Phil Stone pkstone@ucdavis.edu wrote:
Hi Kyle,
I thought of doing that, but reconsidered because it seems like it might lead to versioning problems, namespace clashes, multiple copies of objects and possibly, dogs and cats sleeping together.
Or am I over-thinking it?
Phil
Kyle Klipowicz wrote:
Hi Phil~
Perhaps you could repackage the polyWaveSynth with the required abstractions included, since they are very small in size to make much of a difference? This might eliminate much of the frustration that seems to be plaguing some people.
~Kyle
On 9/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote:
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.
You can fix this by adding your polyWaveSynth directory to your pd-path or copy over poly*.pd to that director.y As polypoly.pd lives in a different directory from polyWaveSynth, it cannot find the objects it creates dynamically. (I'm not sure, if it *should* see them, though, i.e. if this is a bug in Pd.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Kyle Klipowicz wrote:
Phil~
I don't think it would cause problems if you keep them in a subdirectory and addressed the abstractions with abs/foobar.pd type naming.
OK, I think it's starting to sink in. I can keep private "abstraction libraries" inside my abstraction. Another advantage to this is that I can control the versioning of these libraries -- only updating them when I know they don't break [polyWaveSynth].
(Man, I wish the whole PD namespace thing weren't such a ball of confusion, to me at least. I guess it's a natural consequence of the organic growth of PD, though.)
Does Pd search the patch's folder first for all non-native objects before parsing the path?
I was wondering that same thing. If not, this method wouldn't work very consistently.
Also, this will all become resolved once Pd-extended moves forward to including more recent abstractions in its releases (i.e. Pd-extended-0.40 or however it will be branded).
Yes. (Hans? Frank?) please add sssad and polypoly to Pd-extended!
Until then, we just can't really expect the same crowd that Pd-extended is marketed for to know much about cvs and setting up the paths and stuff. It's better to take the high road and avoid elitist isolationism and make things easy as possible for new users to dive into: Pd needs adherents to thrive and become a serious competitor of similar commercial options.
Agreed. I just want to make sure I don't screw up the user's namespace, though. That sort of thing will lose adherents in a hurry. :-)
I think that this object will be a great selling point for new Pd users, especially because of the polyphony. Polyphony management is one of the most annoying things for new (and more seasoned) users to deal with in Pd. Your synth (combined w/ Frank's freaking awesome abstractions) has a great possibility for becoming a template for many awesome modifications and enhancements down the line.
What a nice thing to hear! Thanks, Kyle.
Phil
~Kyle
On 9/9/07, Phil Stone pkstone@ucdavis.edu wrote:
Hi Kyle,
I thought of doing that, but reconsidered because it seems like it might lead to versioning problems, namespace clashes, multiple copies of objects and possibly, dogs and cats sleeping together.
Or am I over-thinking it?
Phil
Kyle Klipowicz wrote:
Hi Phil~
Perhaps you could repackage the polyWaveSynth with the required abstractions included, since they are very small in size to make much of a difference? This might eliminate much of the frustration that seems to be plaguing some people.
~Kyle
On 9/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote:
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.
You can fix this by adding your polyWaveSynth directory to your pd-path or copy over poly*.pd to that director.y As polypoly.pd lives in a different directory from polyWaveSynth, it cannot find the objects it creates dynamically. (I'm not sure, if it *should* see them, though, i.e. if this is a bug in Pd.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
Kyle Klipowicz wrote:
Does Pd search the patch's folder first for all non-native objects before parsing the path?
I was wondering that same thing. If not, this method wouldn't work very consistently.
Pd does search the current directory of a patch before other directories, but that won't help polypoly.pd to find an abstraction in that directory, because polypoly.pd is in a different directory and there is no polywavesynth.pd there! To make polypoly.pd find polywavesynth.pd, the directory of polywavesynth.pd must be in the path!
Anybody still following? ;) I admit, that this is a very confusing issue, so lets use graphics and an example:
.
|-- main
| |-- an_abstraction.pd
| `-- test.pd - uses [../main/using_an_abstraction]
`-- myabs
`-- using_an_abstraction.pd - uses: [an_abstraction]
Assume, test.pd uses this object [../main/using_an_abstraction]. This itself is no problem as we use the object by a relative, fully qualified pathname. test.pd could also use [an_abstraction] of course.
However using_an_abstraction.pd also tries to use [an_abstraction] itself, but here this isn't found, as there is no "an_abstraction.pd" in "myabs" and Pd won't find the other one in "main" from here. This not only happens when using [using_an_abstraction] standalone, but also when it's used as an abstraction itself.
The exact same thing happens with polypoly.pd or singleton.pd when the objects, polypoly or singleton create, aren't in the search path for *polypoly* rsp. *singleton* itself, but somewhere else:
.
|-- main
| |-- CamelSynth.pd
| `-- MySynthWithCamelWords.pd - uses [polypoly CamelSynth 24]
`-- path_to_polypoly
`-- polypoly.pd - is made to use [CamelSynth] above.
Here [polypoly CamelSynth 24] tries to create a lot of [CamelSynth] objects, but those aren't found because there is no CamelSynth.pd in path_to_polypoly/. Duh. So "main" needs to be added to polypoly's search path which means adding it "main" to Pd's search patch or using [declare -path .] in MySynthWithCamelWords.pd
Also, this will all become resolved once Pd-extended moves forward to including more recent abstractions in its releases (i.e. Pd-extended-0.40 or however it will be branded).
Yes. (Hans? Frank?) please add sssad and polypoly to Pd-extended!
Isn't sssad already in pd-extended? Anyway, including them won't solve the problem above, as it's not related to polypoly rsp. singleton being reachable in your custom objects, but your custom objects being reachable for singleton or polypoly.
I'd recommend to make copies of singleton.pd and polypoly.pd into a subdirectory of polywavesynth and use them with local directory prefixes like [./_other/polypoly ...]
I do the same with singleton.pd in the subdirectory "_sssad" of sssad.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Ok, thanks for clearing that up Frank! It's a bit of a tangle, but you gave a nice explanation.
Messing with paths can be a real deterrence for people just looking to briefly demo a patch. It looks like the easiest solution for Phil is definitely to include these abs in a subdirectory then.
~Kyle
On 9/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
Kyle Klipowicz wrote:
Does Pd search the patch's folder first for all non-native objects before parsing the path?
I was wondering that same thing. If not, this method wouldn't work very consistently.
Pd does search the current directory of a patch before other directories, but that won't help polypoly.pd to find an abstraction in that directory, because polypoly.pd is in a different directory and there is no polywavesynth.pd there! To make polypoly.pd find polywavesynth.pd, the directory of polywavesynth.pd must be in the path!
Anybody still following? ;) I admit, that this is a very confusing issue, so lets use graphics and an example:
. |-- main | |-- an_abstraction.pd | `-- test.pd - uses [../main/using_an_abstraction] `-- myabs `-- using_an_abstraction.pd - uses: [an_abstraction]Assume, test.pd uses this object [../main/using_an_abstraction]. This itself is no problem as we use the object by a relative, fully qualified pathname. test.pd could also use [an_abstraction] of course.
However using_an_abstraction.pd also tries to use [an_abstraction] itself, but here this isn't found, as there is no "an_abstraction.pd" in "myabs" and Pd won't find the other one in "main" from here. This not only happens when using [using_an_abstraction] standalone, but also when it's used as an abstraction itself.
The exact same thing happens with polypoly.pd or singleton.pd when the objects, polypoly or singleton create, aren't in the search path for *polypoly* rsp. *singleton* itself, but somewhere else:
. |-- main | |-- CamelSynth.pd | `-- MySynthWithCamelWords.pd - uses [polypoly CamelSynth 24] `-- path_to_polypoly `-- polypoly.pd - is made to use [CamelSynth] above.Here [polypoly CamelSynth 24] tries to create a lot of [CamelSynth] objects, but those aren't found because there is no CamelSynth.pd in path_to_polypoly/. Duh. So "main" needs to be added to polypoly's search path which means adding it "main" to Pd's search patch or using [declare -path .] in MySynthWithCamelWords.pd
Also, this will all become resolved once Pd-extended moves forward to including more recent abstractions in its releases (i.e. Pd-extended-0.40 or however it will be branded).
Yes. (Hans? Frank?) please add sssad and polypoly to Pd-extended!
Isn't sssad already in pd-extended? Anyway, including them won't solve the problem above, as it's not related to polypoly rsp. singleton being reachable in your custom objects, but your custom objects being reachable for singleton or polypoly.
I'd recommend to make copies of singleton.pd and polypoly.pd into a subdirectory of polywavesynth and use them with local directory prefixes like [./_other/polypoly ...]
I do the same with singleton.pd in the subdirectory "_sssad" of sssad.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Kyle Klipowicz a écrit :
Until then, we just can't really expect the same crowd that Pd-extended is marketed for to know much about cvs and setting up the paths and stuff. It's better to take the high road and avoid elitist isolationism and make things easy as possible for new users to dive into: Pd needs adherents to thrive and become a serious competitor of similar commercial options.
~Kyle
My one half cent, everytime I give some try to a new pd-extended it messes up all my pd stand-alone applications because of the freaking pdsettings, that is installed by default, without giving user choice for installing this evil file or not.
Yes, I can understand how that might be frustrating. That's why I really enjoy keeping my personal settings in the .pdrc file on OS X or Linux. With windows, this isn't an option, but a .bat file works well. I definitely agree that the settings department is in need of some revision, it's just a matter of someone with the know-how, free time and determination to set it right.
~Kyle
On 9/9/07, pat pat@mamalala.org wrote:
Kyle Klipowicz a écrit :
Until then, we just can't really expect the same crowd that Pd-extended is marketed for to know much about cvs and setting up the paths and stuff. It's better to take the high road and avoid elitist isolationism and make things easy as possible for new users to dive into: Pd needs adherents to thrive and become a serious competitor of similar commercial options.
~Kyle
My one half cent, everytime I give some try to a new pd-extended it messes up all my pd stand-alone applications because of the freaking pdsettings, that is installed by default, without giving user choice for installing this evil file or not.
On Sun, 9 Sep 2007, Kyle Klipowicz wrote:
Yes, I can understand how that might be frustrating. That's why I really enjoy keeping my personal settings in the .pdrc file on OS X or Linux. With windows, this isn't an option, but a .bat file works well. I definitely agree that the settings department is in need of some revision, it's just a matter of someone with the know-how, free time and determination to set it right.
We don't even agree on what is right. Some want it more platform-dependent, some want it more platform-independent. Some are ok with path dialogs that require people to type full folder names and won't allow more than 10 folders... some are not ok with that... etc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard a écrit :
On Sun, 9 Sep 2007, Kyle Klipowicz wrote:
Yes, I can understand how that might be frustrating. That's why I really enjoy keeping my personal settings in the .pdrc file on OS X or Linux. With windows, this isn't an option, but a .bat file works well.
With windows we can change options with editing the registry. and a .bat doesn't work well because of the interfering registry entries.
I definitely agree that the settings department is in need of some revision, it's just a matter of someone with the know-how, free time and determination to set it right.
Some are able to compile after getting knowledge about the configure options and then have severe chances of having a well configured software, some doesn't want to use a compiler for installing, and have a lot of chances to miss a lot of features proposed by the software, through different kinds of installing processes.
We don't even agree on what is right. Some want it more platform-dependent, some want it more platform-independent.
An optimized plateform-dependent version would implie the use of different application programming interfaces (eg: gtk for gnome, qt for kde, cocoa for OSX, etc...), anyone would like to go on that way?
Some are ok with path dialogs that require people to type full folder names and won't allow more than 10 folders... some are not ok with that... etc
I guess that's why many different softwares proposes different options during the install process. Also I don't know how these choices could be implemented through an installer.
My point is that pd is necessarily messing with configuration files like pdrc or pdsettings that are inevitably interfering between different pd versions, and making impossible the clean and easy development of stand-alone applications.
Patrice Colet wrote:
Mathieu Bouchard a écrit :
On Sun, 9 Sep 2007, Kyle Klipowicz wrote:
Yes, I can understand how that might be frustrating. That's why I really enjoy keeping my personal settings in the .pdrc file on OS X or Linux. With windows, this isn't an option, but a .bat file works well.
With windows we can change options with editing the registry. and a .bat doesn't work well because of the interfering registry entries.
does the "-noprefs" flag not work on windows?
fmasd.r IOhannes
IOhannes m zmoelnig a écrit :
Patrice Colet wrote:
Mathieu Bouchard a écrit :
On Sun, 9 Sep 2007, Kyle Klipowicz wrote:
Yes, I can understand how that might be frustrating. That's why I really enjoy keeping my personal settings in the .pdrc file on OS X or Linux. With windows, this isn't an option, but a .bat file works well.
With windows we can change options with editing the registry. and a .bat doesn't work well because of the interfering registry entries.
does the "-noprefs" flag not work on windows?
fmasd.r IOhannes
Yes it works, I just forgot this option, thank you for reminding me this usefull one.
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
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.
Exactly. I wrote about this issue a bit in my old RRADical paper in section "Communication": http://footils.org/cms/show/1#communication
Generally I think, abstraction developers should keep the number of global receivers to an absolute minimum and avoid them wherever possible. As you are using [sssad] there already is one global receiver builtin, that you can use to address all [sssad] enabled objects. You do this in a similar way to saving and restoring all settings: Instead of restoring all, you just restore only one setting.
Another good approach to keep the number of global s/r minimal is to use [route] and [list prepend]:
[r GLOBAL] | [list trim] | [route one two three] | | | | | ... | ... [s $0-one]
By this you have three targets available using only one receiver. With [list prepend] it's easy to make "settable sends" like this:
[three(
"data" | [two( | |/ [list prepend one] | [s GLOBAL]
or directly:
[one 1 uno eins( | [two 2 duo zwei( |/ [s GLOBAL]
Now replace "GLOBAL" with inlets/outlets and you have reduced the number of global receivers to zero! This is the approach developed and used in RRADical: The rightmost inlet/outlet serves as single border crossing to the internals of a RRADical abstraction, internally then OSCroute is used to multiplex the data sent to such an "OSC-inlet". In [sssad] this is less formalized, but it's the same idea. netpd also uses something like this so I guess it is a kind of design pattern. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
IOhannes m zmoelnig -
Kyle Klipowicz -
Luigi Rensinghoff -
Mathieu Bouchard -
pat -
Patrice Colet
-
Phil Stone