[sdiy] "Synth design questions" or "Learning from Dave Smith"
Edward King
edwardcking2001 at yahoo.co.uk
Thu Oct 18 16:26:06 CEST 2007
As Tom says, plus a little of my own homebrew included inline.
EK
----- Original Message -----
From: "Tom Wiltshire" <tom at electricdruid.net>
To: "jure zitnik" <kokoon at gmail.com>
Cc: "Edward King" <edwardcking2001 at yahoo.co.uk>; "synth-Diy diy"
<synth-diy at dropmix.xs4all.nl>
Sent: Thursday, October 18, 2007 4:12 PM
Subject: Re: [sdiy] "Synth design questions" or "Learning from Dave Smith"
> Jure,
>
> I also think this is a good idea. It's pretty close to the Oberheim
> Matrix12/Matrix 6 interface.
>
> Combined with some buttons to quickly select different groups of
> parameters (VCO1, VCO2, Filter, Filter Envelope, etc etc) and maybe a
> block diagram to give you some sense of the synth's layout, this could be
> really good.
Yeah. A flowchart (tastefully done) on the front panel would give it a real
80's feel.
>
> One possible problem is the resolution of a typical rotary encoder. These
> often have 24 pulses per rotation. This means either that you need some
> way of incrementing faster (various speeds) or you have to sit there
> twiddling for ages to reach the maximum value.
>
> I did some experiments trying to control a parameter value with a rotary
> encoder using the rotation speed to control the increment size. This
> sounds plausible at first: you turn quicker, it goes up more, you turn
> slower, it slows down, you turn really slowly, it steps up one at a time.
> I tried both linear and various non-linear relationships between rotation
> speed and increment size. Unfortunately I found that I couldn't control
> it at all. A single twisting movement starts off from rest (e.g. really
> really slow) and then speeds up to some maximum value, before slowing
> down to rest again. This makes it hard to get a 'feel' for how much or
> how fast you need to turn for a given result. When I changed it to two or
> three bands (e.g. single-step, fast, faster or just single-step and fast)
> I did better, since I learned to turn at the right speed to get the
> effect I wanted. Still, I wasn't everso impressed. A simple pot is much
> easier to get to where you want it accurately. Perhaps with cleverer
> software than I managed to write rotary encoders might be as good, but I
> couldn't find a way.
Measuring rate (i.e the time between pulses) is - IMHO - more effective than
just incrementing every click.
However... as Tom said it can be a bit disconcerting at first and isnt
always easy to get the rate right. Fiddling with the code can usually tweak
it out. An alternative I played with at first was a single pushbutton
underneath a rotary encoder, which when you are holding it down, multiplies
the rate. So assuming you're using a PIC or other processor to handle the
rotary encoder, seeing that the rate button is pressed down causes it to
increment by 2 or more every time a pulse is received, instead of 1 (i
suppose x10 would be a common rate)
>From my point of view, the trick to using a rotary encoder based on rate
(i.e speed rather than number of pulses) is to be conservative with the
relationship and another possibility is to take 1 pulse = 1 increment + a
small rate adjustment based on the time between pulses. This increases the
speed at which you can modify te values, but still keeps most of the control
familiar at the lower end where you're upping by single figures.
The last possibility is my rotary pot idea. Since it uses photo interupters,
you're working soley on rate and dont have the clicks to disorientate
you.Its easy enough to try out. Load up some software tools, take apart a
standard ball mouse, attach a plastic or aluminium wheel to the spindle and
play. using readily available source, you should be able to come up with a
rate system that suits you. just make sure its configurable....
the reason I played with this stuff in the first place was that most
keyboards (especially earlier ones) offered only a datawheel or up-down
buttons to edit parameters so going from 0 to 255 meant 255 jabs or several
revolutions of the wheel. I know data sliders help that but they're absolute
and never in the right position when you need to edit a different parameter.
>
> Regards,
> Tom
>
>
> On 18 Oct 2007, at 10:48, jure zitnik wrote:
>
>> i've also been thinking about the pots/encoders question recently. i
>> kinda figured out quite a cool interface using 8 endless pots (what
>> alesis ion uses if i remember correctly) or even rotary encoders PLUS
>> a 2x40 LCD display. multiply that as many times you want.
>>
>> it would look like this - there are two rows of 4 pots/encoders, one
>> above the lcd and one below. the display has 2 rows of 40 characters
>> each, which means 10 characters of text/numerical representation of
>> the parameter that the pot/encoder controls. i hope you can imagine...
>> for instance, you could have (should be viewed with monospace font,
>> just copy it into a notepad on windows):
>>
>> O O O O
>>
>> VCO1 tune VCO1 fine VCO1 pw VCO1 morph
>> ENV1 att. ENV1 dec. ENV1 sus. ENV1 rel.
>>
>> O O O O
>>
>>
>> when each of the pots/encoders move, the display shows value instead
>> of name of its parameter. you don't need to see the name of the
>> parameter while you're tweaking it. there could also be a dedicated
>> 'disp' key near the lcd, that would toggle the idle display mode, or
>> it could be just a momentary switch to show the parameters' values
>> instead of names. or you could simply use the inverted character
>> (light on dark instead of dark on light) mode to graphically represent
>> parameter's (approximate, 0-10) value and still show the name at the
>> same time.
>>
>> this way, you can stack a few of such combos on a synth, two of them
>> would also make a nice sequencer interface...
>>
>> what do you guys think?
>>
>>
>> On 10/18/07, Edward King <edwardcking2001 at yahoo.co.uk> wrote:
>>> Tom,
>>>
>>> if you're likely to continue to expand on your system and possibly
>>> include
>>> polyphony and more complex audio engines, I would look at a digital
>>> interconnect solution with reasonable bandwidth.
>>> Bandwidth gets eaten up pretty quickly for realtime control and if you
>>> are
>>> likely to expand on your system, you'll lose nothing by jumping in
>>> sooner
>>> rather than later...
>>>
>>> My protocol specs and designs are pretty much ready for implementation
>>> for
>>> lower speed stuff (still a little work for the higher speed serial).
>>> Ive
>>> called it Simple Time Critical Audio Protocol and its an 8 bit
>>> addressable
>>> packet switch system. Given that its unlikely to be hosted on a system
>>> needing more than 255 devices, it should be okay for playing around
>>> with.
>>>
>>> Is there room on your devices for drivers etc?
>>>
>>> EK
>>>
>>> ----- Original Message -----
>>> From: "Tom Wiltshire" <tom at electricdruid.net>
>>> To: "synth-Diy diy" <synth-diy at dropmix.xs4all.nl>
>>> Sent: Thursday, October 18, 2007 1:28 AM
>>> Subject: [sdiy] "Synth design questions" or "Learning from Dave Smith"
>>>
>>>
>>>> Hi all,
>>>>
>>>> I've been looking at the very interesting guts-out photos of the new
>>>> DSI
>>>> Prophet 08:
>>>>
>>>> http://prophet5.org/prophet08/
>>>>
>>>> I'm always very interested in this kind of thing since it allows me
>>>> to
>>>> see a little of how other people have tried to solve design problems
>>>> that
>>>> I'm looking at myself as part of my monosynth project.
>>>>
>>>> Before I mention that, I'd just like to point out the RJ11
>>>> programming
>>>> connectors for each of the processors on the voice board/ main board -
>>>> custom firmware for your DSI Prophet, anyone? The mind boggles!
>>>>
>>>> Ok, now my questions:
>>>>
>>>> 1) Should the main control processor talk to the voice board
>>>> digitally or
>>>> using control voltages?
>>>>
>>>> Originally, I thought I'd use control voltages, since it's simple and
>>>> keeps the analogue spirit of the voices. I had this in mind when I
>>>> did my
>>>> PIC-based LFO and ADSR designs.
>>>> However, it does seem a little bit daft to have one processor take
>>>> digital information (patches from memory) and use an D/A to convert
>>>> it to
>>>> a control voltage, just so that another processor (say, a PIC- based
>>>> envelope generator) can use a A/D to convert it back to a digital
>>>> parameter. Consequently, I'm currently wondering about using a SPI
>>>> connection instead.
>>>>
>>>> 2) Should the front panel of a programmable synth use pots or rotary
>>>> encoders?
>>>>
>>>> Again, originally I'd thought pots. This works reasonably well whilst
>>>> you
>>>> have a individual pot for each parameter, although even this is a bit
>>>> of
>>>> a pain with a programmable synth, since as soon as you change
>>>> program,
>>>> none of the knobs tell you anything. When programming my Korg
>>>> Polysix, I
>>>> always have the 'manual' button pressed, so that the sound I hear is
>>>> the
>>>> one I can see on the panel. And that's a simple instrument.
>>>> However, it would be nice to have multiple LFOs or envelopes that
>>>> share
>>>> controls, since this gives much more flexibility without making the
>>>> panel
>>>> enormous . The Prophet 08 is an example of what I have in mind - its
>>>> four
>>>> LFOs share the same group of controls, with simple buttons to select
>>>> which one to edit. The trouble with this is that as soon as you
>>>> switch to
>>>> the next LFO, the knobs don't tell you anything again. Given that
>>>> they
>>>> don't, are rotary encoders easier to work with since you can just
>>>> pick up
>>>> the value from where you are without having to worry about the end of
>>>> the
>>>> track? As a technical issue, how does one go about monitoring 64
>>>> rotary
>>>> encoders?
>>>> So far, I feel the only really convincing solution to this is
>>>> encoders
>>>> with LED rings like Clavia use, but resolution is a problem, so you
>>>> still
>>>> need a LCD to see the true value, although the lights might give a
>>>> nice
>>>> guide. Also, building a serious synth panel with as many knobs as the
>>>> Prophet 08 has would require some serious number of LEDs, and
>>>> similarly
>>>> serious amount of current to light them all.
>>>>
>>>> At one point, I'd made decisions about many of these things, but as I
>>>> learn more, I keep finding more sophisticated ways to do things, and
>>>> then
>>>> wonder if the earlier decision was really so wise in the light of the
>>>> new
>>>> information. I guess I should just get on and build the simpler
>>>> instrument I designed originally and save the clever stuff for the
>>>> Mk2.
>>>>
>>>> Thanks!
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Synth-diy mailing list
>>>> Synth-diy at dropmix.xs4all.nl
>>>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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