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__