Hey Dave!<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Firstly it's great that you have your branch up and running but don't<br>
worry overmuch about breaking things.<br>
<br></blockquote><div><br>I'm happy, I haven't been this excited about coding for music in quite a while.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

I feel sorry for you that your first experience of C++ is fluxa, it's<br>
hardly a typical project - a lot of that code dates back to this:<br>
<a href="http://www.pawfal.org/Software/SSM/" target="_blank">http://www.pawfal.org/Software/SSM/</a> and before, other parts are super<br>
experimental - and the synth core is all realtime thread stuff.<br>
<br></blockquote><div><br>I noticed the references to the Spiral Synth stuff, yes, I'm not sure this is such a bad project, maybe a-typical, but Fluxa is a *very* simple synth (syntax-wise) which also makes the modules quite simple so I can find my way around with relative ease.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Design wise, again, when things are screwy (like distort cv being upside<br>
down) feel free to just fix them. Keep sending emails and then we can<br>
argue if needbe :)<br></blockquote><div><br>Ok, cool. That I will fix. Generally I'd like to stick to the 0-1 range for modulation. Because of this, this morning I started to work on some LFO nodes. These output in that range and take a period as a argument, instead of a frequency. They also wait for their trigger time to start. To match this I adapted xfade to take a mix between 0 and 1 too, that way it makes more sense and plays nicely with ADSR.<br>
<br>Part of the point to that is that I want to do a node that uses a CV signal to scan through a sample, so for that to sound good for looped sounds (primitive time-stretching, etc) I needed a synced oscillator, which led to this. They are a extension to wavetable and work in the same way, aside from those parts. I also implemented reverse-saw for this; it was there and for lfo's it makes sense.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
In the larger scale, be aware there is a kind of limit to the number of<br>
"unit generator" nodes fluxa can have, as it needs to pre-allocate them<br>
at startup (no new or delete allowed in realtime threads). It currently<br>
allocates 70 of each synth node and 2000 terminal nodes - so more node<br>
types = more memory usage (not that it's that high but...). I think all<br>
your additions are good, but there is as ever a risc vs cisc trade off<br>
to be kept in mind and discussed.<br>
<br></blockquote><div><br>Ah! That was the strange loop I didn't quite get which loops over all the nodes at startup :-). In that case I know of one spot where quite a bit of memory could be saved. All of the osc's (and now lfo's) each have their own wavetable and all of those have all of the wave arrays. On to of that, at startup all of those waves are independently created (I think...). Since those are all the same a single set of tables, which all oscs could use, should do, saving nearly 70 * NumOfOscs&Lfos * waveshapes * table-length in  floats. I'm not sure how much that is but that probably that's the biggest chunk of memory outside of the samples that could be saved in one swoop. <br>
<br>More generally; I think I'll just keep experimenting and this memory thing sounds like a good reason to go back every once in a while and check what experiments were successful and which ones don't get used very often. The ones we don't use can then be axed to make space for nicer things. I think this potentially also pleads in favour of nodes that can perform multiple tags, like the oscs, the effects and so on. There might not be a need to reserve space for 70 of each kind of those; a general pool of those types, then depending on the type switches to configure them might be cheaper?<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
formant - this is fixed now, a float/double issue. It used to work in<br>
older compilers for some reason.<br>
<br></blockquote><div><br>Jay! Good that you found this because that sound exactly like the kind of thing I would not have found in a reasonable amount of time.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

As for this:<br>
<a href="http://docs.racket-lang.org/reference/sequences.html?q=sequence#%" target="_blank">http://docs.racket-lang.org/reference/sequences.html?q=sequence#%</a><br>
28part._.Iterator_.Generators%29<br>
<br>
it's exactly the kind of thing we should be experimenting with, along<br>
with: <a href="http://docs.racket-lang.org/frtime/" target="_blank">http://docs.racket-lang.org/frtime/</a><br>
<br>
There are a lot of crazy language experiments in racket waiting to be<br>
(ab)used :)<br><br></blockquote><div><br> Cool! I really want to try to do that sample-abuse thing, then I'll go back to actually using this for some music for a bit. Just compiling C++ all the time is probably not a good thing for smokers like myself :-).<br>
<br>Yours,<br>Kas.<br></div></div>