[Fluxus] some fluxa questions answered

[Kassen]

Hey Dave!

Firstly it's great that you have your branch up and running but don't
> worry overmuch about breaking things.
>
>
I'm happy, I haven't been this excited about coding for music in quite a
while.


> I feel sorry for you that your first experience of C++ is fluxa, it's
> hardly a typical project - a lot of that code dates back to this:
> http://www.pawfal.org/Software/SSM/ and before, other parts are super
> experimental - and the synth core is all realtime thread stuff.
>
>
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.


> Design wise, again, when things are screwy (like distort cv being upside
> down) feel free to just fix them. Keep sending emails and then we can
> argue if needbe :)
>

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.

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.


>
> In the larger scale, be aware there is a kind of limit to the number of
> "unit generator" nodes fluxa can have, as it needs to pre-allocate them
> at startup (no new or delete allowed in realtime threads). It currently
> allocates 70 of each synth node and 2000 terminal nodes - so more node
> types = more memory usage (not that it's that high but...). I think all
> your additions are good, but there is as ever a risc vs cisc trade off
> to be kept in mind and discussed.
>
>
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.

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?


> formant - this is fixed now, a float/double issue. It used to work in
> older compilers for some reason.
>
>
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.


> As for this:
> http://docs.racket-lang.org/reference/sequences.html?q=sequence#%
> 28part._.Iterator_.Generators%29
>
> it's exactly the kind of thing we should be experimenting with, along
> with: http://docs.racket-lang.org/frtime/
>
> There are a lot of crazy language experiments in racket waiting to be
> (ab)used :)
>
>
 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 :-).

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20110330/dff4ac87/attachment-0001.html>