[Fpga-synth] N-Operator FM

[Veronica Merryfield]

I would do it in a slightly different way.

Two register files of values arranged as lists or structures.

The first would be the patch data - these would be hard values per  
note and pointers, offsets in the second list of where data is to be  
found or put.

The second would be the operational data, or state data.

The processing engine would start at the top of the list and work  
down. The list would be arranged as best as possible to have the  
entries that need data from other entries further down the list but  
recognising that some data would come form the previous iteration.

The reason I had the outputs being accumulated was that there need be  
one entry per unit that indicates where the output need be  
accumulated. The down side to this is if one wanted a result from one  
of a group it would need another unit but I suspect this won't happen  
often.

The envelope processing needs some thought. They don't all need to be  
calculated every iteration since by nature they are a lot slower, so  
one might do one envelope per iteration, so once every 64 iterations  
in a 16 polyphony by 4 unit. I would also have a number of units have  
as many polyphony as the units per voice will allow rather than fixing  
the polyphony. The software can figure out note assignments and voice  
stealing.

There may be better ways to utilise the parallel nature of the FPGA -  
several unit processors for instance and distribute register files may  
give better floor planning, device utilization and execution speed.  
There may be optimizations to be had along the line.

I envision the envelope being a list of value pairs along with a type  
identifier. The basic type is a target value and time entry. There  
needs to be a loop end type that has an index to jump to (sustain  
being to jump to the previous entry say assuming a jump takes zero  
time in the processing chain i.e. the jump is made and the new entry  
processed) and some way to control release unless it is to ignore the  
jump. Care would be needed in ensuring the loops aren't long or one  
could have release as a jump to the point after the loop instruction  
(this could be something that is an info entry at the start of the  
envelope list so that the envelope processor knows where to go on a  
note off event).

Veronica


On 4-May-09, at 12:41 PM, Scott Gravenhorst wrote:

> Thanks again to Veronica B. for her multi-operator FM machine  
> suggestion.
>
> I was thinking about this and came up with a rough possible  
> implementation
> idea.
>
> What I envision is a specialized programmable state machine.
>
> The operators would be RAM based and (in this simple example) would  
> all
> share the same computational hardware.
>
> A patch would be stored as instructions in block RAM(s).
>
> The programmable state machine would work with the data and  
> instructions in
> that RAM.
>
> At least two instructions would be necessary (forgive me, this is  
> new in my
> brain) - a GET instruction and an EXEC instruction.  GET would cause  
> the
> state machine to access and cache a previously calculated output from
> another (previously computed) operator structure.  An EXEC instruction
> would cause the selected operator structure to compute and store in  
> RAM
> it's next output.  This way, pointers stored in the instruction  
> stream RAM
> would define the connections between operator structures.  If a GET
> instruction retrieves an operator structure output value needed by  
> more
> than one downstream operator structure as input, there could be one  
> GET for
> that and then several EXEC instructions following it.
>
> The programmable state machine could view the instruction RAM as a  
> linear
> script executed once per sample time (not sure if looping is  
> required or
> expedient).  Only the operator structures that are actually used in  
> a given
> patch are calculated.
>
> There would be a need for some kind of "assembler" to translate the  
> patch
> language into machine language instructions, but this doesn't seem  
> horrible
> to me, I've written a few assemblers before.
>
> This is very preliminary newbie thinking so please be kind...  (c:
>
>
> -- ScottG
> ________________________________________________________________________
> -- Scott Gravenhorst
> -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/ 
> FPGA_synth/
> -- FatMan: home1.gte.net/res0658s/fatman/
> -- NonFatMan: home1.gte.net/res0658s/electronics/
> -- When the going gets tough, the tough use the command line.
>
> _______________________________________________
> Fpga-synth mailing list
> Fpga-synth at rubidium.dyndns.org
> http://rubidium.dyndns.org/cgi-bin/mailman/listinfo/fpga-synth