Yahoo Groups archive

200e

Index last updated: 2026-04-28 22:38 UTC

Message

Re: [200e] Re: 250e question

2008-08-20 by ezra buchla

On Wed, Aug 20, 2008 at 2:20 PM, kkonkkrete <kkonkkrete@yahoo.co.uk> wrote:
>
>> you could say that the second case is true, in that there is a
>> computer in there with realtime memory. in the 250e, it is
>> continuously updating this realtime memory (and the cv output) based
>> on the knob position of the *current stage,* or based on something
>> else like an external cv input if it's in that mode.
>
> OK, this makes sense, of course. But as I only care about the voltage
> as each stage is reached, this is a moot point: presumably for normal
> function this updating must be pretty damn quick after the stage is
> addressed.

yep. to the outside world it looks quite smooth.

>> the current behavior of the 250e is that it's supposed to read the
>> physical knob positions when it powers up, but it's slightly buggy
>> because of a conflict with the interpolation algorithm (which i'll get
>> to in a second) and because the knobs aren't all scanned at once but
>> rather at each stage of the sequence (which allows each knob to be
>> scanned at a much faster update rate). so it's tricky, and right now
>> the accuracy at startup depends on the difference between the stored
>> values and the phyiscal values. one of our programmers is working very
>> hard on making it better. at the moment i'm afraid the best way to get
>> consistent behavior is to use the thing in conjunction with a 225.
>> it's somewhat of a trade-off, but i personally consider it more
>> convenient than old drifty analog sequencers.
>
> OK, but if the knobs haven't moved at all since I set the stored
> values, the interpolated value at runtime will presumably be the same
> as both the knob position and the stored value (if x=y and
> z=ax+(1-a)y, where 0<a<=1, then z=x=y). Or is there a resolution
> issue here that I haven't thought of that could throw things off?

no, there's no resolution issue on that level. i think if the knobs
are at the same position as the preset, everything works as expected.
the problem is that there's no way to store presets without the 225;
it doesn't happen automatically; one reason is that flash memory has a
long but finite lifetime and it can't be written to every time a
parameter changes.

> To be honest I don't really care about multiple presets: the only
> reasons I would get a 225e would be (i) syncing to MIDI clock, (ii)
> making use of MIDI performance interfaces, and (iii) remembering the
> sequencer settings. From what you've said, I *think* I can still wait
> with the 225 until I upgrade to the 12-cabinet next year.
>
>> a behavior that i maybe like better is to have the 250e alwasy load
>> preset zero at startup, so you can have some control over the
>> "default" behavior, and to make it amenable to the autonomous preset
>> storage behavior that we implemented in the 210, 291 and others. even
>> this is kind of difficult because of the realtime updating that i
>> mentioned before, but fixing it is a high priority.
>
> Not sure I like the sound of that (for me, right now). That would
> REALLY force you to have a 225e.

sorry, i wasn't clear enough. we have a new behavior in some modules
(the ones with a lot of complicated digital settings) where the remote
enable button functions as a "store preset zero" button if there is no
225e present in the system, and then preset zero is always loaded on
startup. it's not quite transparent but its much better than starting
from scratch all the time (i wanted this because i was using e.g. a
two-panel with 210 and 291 in performances...)

i think this behavior needs to be implemented in the 250e to make it
totally functional, in my opinion, at least for people like yourself
(and myself, sometimes) who don't want to have to use a 225 all the
time. but there's an obstacle because the preset recall behavior at
startup is buggy for pretty complicated reasons. this will get figured
out as soon as possible; but in all honesty that might mean a couple
months or more.

>>
>> > This makes me think of a more general problem with discrepancy between
>> > pot positions and stored values in the 200e as a whole: how is the
>> > conflict resolved? If you touch a knob after loading a preset, does
>> > the value jump to the new pot position, or is there a 'latch' mode
>> > like on some other synths (not sure which is better / worse, I don't
>> > really like either)?
>>
>> neither do we. the 259e was the first module in the series and it used
>> a latch, but don has since designed a quite elegant algorithm to
>> smoothly interpolate between the physical knob positions and the
>> stored parameter values at all times. basically the knob range is
>> rescaled until its position matches the stored position, at which
>> point it resumes its default scaling with no perceivable transition.
>> this is true for nrealy all of the knobs in the system.
>>
>
> Now that sounds cool. Never encountered that before. So let me get
> this straight: suppose the stored value is 0 (min) and knob is at 10
> (max), then when you turn the knob, nothing will happen until you hit
> zero. Whereas, if stored is at 5 (midpoint) and knob is at 10, when
> you turn the knob, you'll start decreasing from 5 at a rate that is
> constantly changing until (at some point), you 'catch up' and knob
> position becomes absolute (rather than relative). I guess the only
> problem is if the knob is at 10 you can't increase above 5 without
> going down a little first (in fact, do you have to pass through the 5
> position to be able to go up from there?). Have I got that right? In
> practice I'm sure it works well ...

that's about right. obviously if the knob is at 10 you can't increase
it anyway, you have to "ratchet" down and back up, or just sweep it
back and forth to get the full range back. but in general, moving a
knob in one direction will give you an immediate parameter change in
that direction; way better than jumping around or having a
fustratingly non-responsive latched knob.

>> > Is there a way to force a module to use its front panel settings
>> > rather than whatever is stored in patch memory (I can imagine, for
>> > example, pressing and holding 'remote enable' for a few seconds, to
>> > toggle between the front panel values and the stored values).
>>
>> that's a nice idea. the remote enable button is already overloaded but
>> it's a nice idea. currently you can make sure you are reading the full
>> range of each knob by sweeping it between its extremes.
>>
>> forcing each module to re-scan its panel with a switch might be cool,
>> but it also might be less useful than you think. the patch recall is
>> really kind of magical, and all knobs always respond smoothly and
>> pretty much as expected.
>>
>
> I can believe that. On the other hand I use this function all the
> time with my Creamware Minimax.

it's definitely a cool idea that i haven't thought of, and now it is
on my mind. we're trying to stabilize the feature set of the 200e
though (so we can start making other stuff!), so i dunno if you'll
actually see that. maybe it could be easily implemented as a global
menu item from the 225, but on the individual modules we have a lot of
feature ideas and precious little interface left.

>> > Sorry for all these questions, I just want to make sure I order
>> > exactly what I need. By the way, quantization doesn't really bother
>> > me: many of my other analogue sequencers don't even have it. As long
>> > as you can adjust the sequencer CV's finely enough to hit the sweet
>> > spot, I don't care.
>>
>> cool. accurate pitch is of course a crucial and difficult problem
>> because of the incredible resolution of the ear in the frequency
>> domain. the buchla solution has always been to allow arbitrary scaling
>> of frequency modulators. this means that it is possible to trade range
>> for accuracy at will, or vice versa. i think it is still a good system
>> that works quite well, and has managed to accomodate a wide variety of
>> technical limitations and tolerances in the last 35 years.
>>
>> i might as well freely admit that the 250e is not an analog sequencer,
>> it has a digital brain and an analog-style interface layer. in some
>> respects its character is noticeable, but in other respects it kind of
>> transcends such discriminations with a truly freaky set of
>> capabilities...
>>
>
> Oh I know it's not analogue. Never made much sense to me to use
> analogue for stored voltages anyway. What I do care about is
> directness of the interface, and being able to control it with CVs and
> gates.
>
>> > Thanks a lot!
>>
>> no prob
>>
>> -eb
>>
>> > --- In 200e@yahoogroups.com, "ezra buchla" <ezra.buchla@> wrote:
>> >>
>> >> that's right. getting autonomous preset storage in the 250e is a
>> >> priority but it's proven difficult. next firmware rev.
>> >>
>> >> fort now, you must use a 225.
>> >>
>> >> On Wed, Aug 20, 2008 at 1:24 AM, JB <ringmodulator@> wrote:
>> >> > This is something i know Ezra has been working on implementing
> in all
>> >> > modules, but im not sure if the 250 has this feature yet. I would
>> >> > recommend getting the 225e though, being able to switch presets is
>> >> > very valuable if you plan to use the system live, its a great
> feature,
>> >> > i use it all the time.
>> >> >
>> >> > 2008/8/20 kkonkkrete <kkonkkrete@>:
>> >> >
>> >> >>
>> >> >> How much does the Arbitrary Function Generator remember at power
>> > down?
>> >> >> If you don't have a 225e to store the settings, does the 250e
> recall
>> >> >> all data for the current settings, or do you have to reprogram it
>> >> >> every time you power up (or load the program from the 225e if you
>> > have
>> >> >> one)?
>> >> >>
>> >> >> Sorry for this basic question ...
>> >> >>
>> >> >> Thanks,
>> >> >> KKonkkrete
>> >> >>
>> >> >>
>> >> >> ------------------------------------
>> >> >>
>> >> >> Yahoo! Groups Links
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.