[sdiy] Prom generating TOS like MK50240 bits..
nvawter at media.mit.edu
nvawter at media.mit.edu
Mon Apr 30 16:46:21 CEST 2012
Hey friends,
I was finally able to test "Divider Party," my Top Octave Generator
chip implemented in a CPLD:
http://www.youtube.com/watch?v=dlxtTySJ2L0
Some specs:
Chip: Altera 3064
Macrocells: available: 64
Macrocells used: 63
Cost: $2.16 in single quantity
Socket conversion/regulator: Kemani from http://www.amani64.com
Chromatic outputs available: 13
Minimum octave shift: -4
Worst-case accuracy: <= 2.0%
Max input frequency: > 200 MHz
Output waveforms: 50% duty cycle square waves
Software Environment: Quartus II, free!
CPLD Programmer: Asian import USB Blaster
Bugs: 1, divide-by-16 output is too high in frequency
Quoting Scott Gravenhorst <music.maker at gte.net>:
>
> Harry Bissell <harrybissell at wowway.com> wrote:
>> doesn't this just scream "FPGA" ? :^)
>>
>> H^) harry
>
> It does to me, but that's hardly a surprise. I've designed more
> than one synth that is based on a
> TOG. MIDI note numbers are converted to two 4 bit values, a scale
> value and an octave value. The
> scale value is presented to the TOG ROM as it's address to get a
> phase increment which is then left
> shifted by the octave number. Left shifting means that octaves will
> all be perfect octaves. One
> reason I did this was to keep the ROM small (needs only a 16
> location ROM) at the expense of
> unmodulated tones being "boring" when used as intervals.
>
> A difference between what I am doing and the MK50240 would be
> precision. Depending on sample rate,
> my phase accumulators are usually in the range of some 48 bits and
> the phase increment values in
> the tuning ROM are around 22 bits (which are then left shifted for
> octave). The ROM is actually a
> dual ROM which gives 2 values for each note and an interpolator
> outputs a final phase increment.
> The interpolator facilitates pitch modulation which is nice for
> keeping the sound from being
> sterile by using something like an LFO (or LF noise) and also for
> the pitch wheel.
>
> The nice thing about an FPGA is that even low end units are capable
> of providing the logic for the
> TOG as well as the rest of the synth.
>
>
>> ----- Original Message -----
>> From: nvawter at media.mit.edu
>> To: synth-diy at dropmix.xs4all.nl
>> Sent: Fri, 20 Apr 2012 15:22:34 -0400 (EDT)
>> Subject: Re: [sdiy] Prom generating TOS like MK50240 bits..
>>
>> Quoting Tom Wiltshire <tom at electricdruid.net>:
>>
>>>
>>> On 19 Apr 2012, at 18:15, nvawter at media.mit.edu wrote:
>>>
>>>> Quoting Tom Wiltshire <tom at electricdruid.net>:
>>>>
>>>>> Thinking about it more, though, it's the least common *multiple*
>>>>> which is crucial, not the factors.
>>>>> Multiply all these, Least Common Multiple = 1.4163158499841E+22
>>>>>
>>>>> Still very big, but we're under a yottabyte this time!
>>>>
>>>>
>>>> Ah yes! Glad you reminded me it's least common multiple... that
>>>> reduces my implementation to:
>>>> 32*27*25*7*17*19*23 = 1123264800
>>>> l(.)/l(2)
>>>> 30.06505092474673512219, e.g. 2^30.065
>>>>
>>>> So, that's just a little over 1 Gig addresses!
>>>>
>>>> Shockingly enough, you can by 1Gb flash mems for ~$6 now.
>>>> Since you'd need 11-12 of them (one for each note), that's about $66....
>>>> or, just use a single 16Gb flash chip for $11.73!!!
>>>>
>>>> If you were to clock it at e.g. 14080 kHz, the /32 output would
>>>> result in A440 and the chip would only repeat every 19 hours!
>>>>
>>>>
>>>> With some interesting features... for instance, you could scramble,
>>>> randomize, wow, flutter, and otherwise perturb the outrageously
>>>> long word inside the memory to get variations and reduce
>>>> phase-locking...
>>>>
>>>
>>> One thing I don't understand; are you using more than one bit for
>>> each output? if so, why? The point is that if we had a 16-bit
>>> memory, we could store the next state for all 13 outputs and have 3
>>> bits left over. In which case we need only one large 16-bit memory,
>>> not 12.
>>
>> oops yeah I could have been clearer about that. for now, I'm only
>> considering one-bit output per note... so when I said 1Gb chips for a
>> single voice, I meant literally 1 Gb of storage, which in practical
>> reality means 128Mb of addr and 8b of data, so you'd have to have a
>> demux in there to get the full 1G of data for the single voice.
>> That's obnoxious :) So 1G of addr by 16b of data chip would be much
>> smarter. And yeah I'm saying that the output would only require 12
>> (11) of those 16 bits. The other 4-5 would be wasted, or alternates...
>>
>>
>>> However, since the problem gets worse the more outputs you try and
>>> combine onto a single chip, perhaps it's worth looking at the
>>> problem in pieces.
>>
>> oh mi god! you just burst the problem space wide open again, just
>> when it was getting tractable :) Seriously, not a bad idea to group
>> the outputs into more manageable sizes. I'm not smart enough to
>> partition that without going through all possible combinations.
>>
>> I think, using my product of 7 factors approach (32*27*25*7*17*19*23),
>> it would be possible to loop through all 128(64) combinations of
>> putting each factor into one or the other chip, and choose the
>> combination that results in the lowest common multiple. e.g.
>>
>> 32*27*25*7*17*19 in one chip, 23 in the other
>> 32*27*25*7*17 in one chip, 19*23 in the other
>> 32*27*25*7*17*23 in one chip, 19 in the other
>> 32*27*25*7*19*23 in one chip, 17 in the other
>>
>> ok I'm silly, I just wrote the program that does it (see source and
>> output at
>>
>> https://docs.google.com/document/d/1qLgSr9A_BqfQit-rcODdxahpwE4Qw0nuAJLp2-n10VU/edit).
>> The optimal way seems to be a combination of: 52003 in one chip
>> and 21600 in the other chip. Note that these are below 64k!!!
>>
>> 32*27*25 = 21600
>> 7*17*19*23 = 52003
>>
>>
>> although -- it's note quite valid for the problem b/c those values
>> aren't the actual values needed to make sounds... I would shift it
>> around and stuff those "ugly" (prime) dividers together on the same
>> chip. That would fit on an 8k chip and a 256k chip :)
>>
>> 17*19*23 = 7429
>> 32*27*25*7 = 151200
>>
>>
>>> Say we broke it into 4. Which outputs would you put on each chip to
>>> get the smallest possible memory size? (e.g. which ratios combine to
>>> give the smallest least common multiple?).
>>> This would reduce the problem enormously, although it would require
>>> 4 sets of address counters. For example 478x358x239 = 40,898,636 -
>>> only 27 bits required for the address!
>>>
>>> To be honest, I still don't think this is a viable way to go. I've
>>> thought quite a lot about this problem on and off over the last few
>>> years. It's a classic "can it be done on a $1 PIC?" problem, which
>>> is why it appeals to me - I don't actually need or really see the
>>> point of a top octave generator chip.
>>
>> I agree that as a final, shipping, production solution TOGs are
>> probably not sensible. However, for exploring and experimenting, it's
>> very convenient to have simultaneous access to all 12 outputs. I'm a
>> programmer so I see things different from the rest of the crew I work
>> with... they like things at the chip-level, having come from the
>> circuit-bending direction, so they're fond of making tangible
>> connections. I think it's got something to do with constructive anger
>> which doesn't translate well into virtual activities :)
>>
>> One other consideration when comparing e.g. CPLDs to uControllers
>> would be the maximum clocking frequency. a CPLD might be able to
>> reach 200MHz or so, while a uController might be hard-pressed to work
>> function at 1 MHz, unless code was 100% optimized. So, part of the
>> decision depends on how fast your source frequency is.
>>
>> And I guess the other part is complexity/number of chips/board space.
>> The whole reason I decided to use a CPLD in the first place is because
>> when I tried it with discrete logic, it was too big to fit on a PCB of
>> the eval version of Eagle :)
>>
>> BTW, w/r/t to reducing phase locking, it might be possible to
>> introduce noise into the clock. For example, in my CPLD "Divider
>> Party," every divider is clocked by one input... but why not use
>> separate clocks into the chip and physically interfere with them? I
>> like your idea of using the thermally-influenced internal oscillators
>> even better :)
>>
>>
>>> Anyway, my best guess for a solution would be to use 12 super-small,
>>> super-simple chips to simply output the states for *one* note. This
>>> requires a maximum of 478 different outputs, and perhaps twice that
>>> for ROM if it takes you two instructions to output a literal to a
>>> pin. So you'd take 12 of these:
>>>
>>> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en019863
>>>
>>> (6-pin, SOT-23, costs $0.30 - total under $4)
>>> These all have their own internal 4MHz RC clock, so you won't get
>>> phase locking, and you will get some temp drift - hey, it's almost
>>> an *analog* solution! Alternatively, find a similar chip that
>>> accepts an external clock and clock all 12 uPs from one master
>>> clock, locking the phases and making it sound like a cheap Italian
>>> organ from the 70s.
>>> Currently, that's the best way I can see - but I don't use
>>> CPLD/FPGAs, which probably offer another route.
>>
>>
>> yeah, that's actually a really good an interesting solution, too!
>>
>>
>>
>>> Regards,
>>> Tom
>>
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>>
>> --
>> Harry Bissell & Nora Abdullah 4eva
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>>
>
> -- ScottG
> ________________________________________________________________________
> -- Scott Gravenhorst
> -- FPGA MIDI Synth Info: jovianpyx.dyndns.org:8080/public/FPGA_synth/
> -- FatMan Mods Etc.: jovianpyx.dyndns.org:8080/public/fatman/
> -- Some Random Electronics Bits:
> jovianpyx.dyndns.org:8080/public/electronics/
> -- When the going gets tough, the tough use the command line.
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>
More information about the Synth-diy
mailing list