[sdiy] Top Octave Generator (was Chinese MG-1s??!?)

[Veronica Merryfield]

I suspect you could probably roll any differences of 3 to 4 cycles say  
together thus reducing the table size. Now if these micros could have  
an instruction 'stall Rs' that stalled the micro for a number of  
clocks, the code would be very simple - just walk an index down a  
table outputting the word from one table, waiting the amount in the  
other table then incrementing the index. The table of time differences  
could have the code execution time for the loop removed hence the  
adding events together.

I am surprised it was as little as 5820 distinct events. So, about  
15KB for the data table and a hand full for the code. Neat.

On 30-Apr-08, at 5:09 PM, Tom Wiltshire wrote:
>
> On 30 Apr 2008, at 22:08, Veronica Merryfield wrote:
>
>>
>> On 30-Apr-08, at 10:57 AM, Eric Brombaugh wrote:
>>> Veronica Merryfield wrote:
>>>
>>>> The way to make this work is not to have 12 dividers but to use a  
>>>> rolling scheduler.
>>>
>>> Very nice approach.
>>>
>>>> A little intelligence will be needed to handle events that come  
>>>> close together.
>>>
>>> You said a mouthful there. Traversing the queue to schedule the  
>>> next instance of the current edge, then fetching the top of the  
>>> queue to set the timer for the next event is probably going to eat  
>>> up enough time to make event crowding a very real issue. A fun  
>>> problem for someone. :)
>> Since the event set is limited, or perhaps I should say very well  
>> defined, and although I know there will be occasions where thing  
>> will get congested, I think it would work, The queue is a simpler  
>> problem than most queues, again it is limited and well defined, and  
>> I think there are a number of optimization opportunities.
>>
>> Also, the description queue here does not mean a linked list. For  
>> instance, if the event structures had an extra field that is a next  
>> index, the events could be an array of structures and a single  
>> 'next_index' variable. The rejigging of the queue is about changing  
>> the times, the next index fields and the next_index. At the times  
>> where it gets congested, the event edges might be off by a few  
>> clocks but that should be no real issue and could add to the  
>> character or effect :) If you wanted to ensure the errors didn't  
>> accumulate, you can correct for delayed events, again, that happens  
>> in ECUs.
>
> I generated a list of the events to have a look at. Makes quite  
> interesting reading. There are quite a few occasions when things do  
> get quite thick, but often you've got 20 or 30 cycles between events  
> at least.
>
> http://www.electricdruid.com/TopOctave.html
>
> I haven't started thinking of an algorithm to work out which bit  
> changes next, but maybe you don't need one, since there's only 5820  
> events.
>
> Anyone still tempted?
>
> Regards,
> Tom
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy