A couple suggestions

dotlogic

Hi Julian, great work on this little machine. I haven't had much time to play with it yet, but I'm loving how quickly you can just jam out an idea organically.

So a couple ideas,

Firstly, I wonder if it is possible to have tracks playing from different patterns at the same time. ie; In performance mode pattern 1 is running, I'd like to be able to trigger the snare track from pattern 2 but let the other pattern 1 tracks continue.

I imagine that holding down a pattern button, and then pressing the corresponding voice button could work from a UI perspective. visual feedback could be that any pattern that is involved in current playback is lit, and will count in like normal. I don't know if you can control brightness via software but if so you could have the "Primary pattern" lit at full brightness, and others less bright. The primary pattern would be defined as the last pattern triggered completely so long as a track from it is still running.

In a live/jam situation this would be useful I think, as long as you could keep track of what is going on.

Having said all that, This might be beyond the scope of what the sequencer is for, and if the software was not designed with this in mind it could require a bit of work. It may also break the pattern chaining logic. Anyway, just an idea.

Secondly, (and I'm sure this has been raised already) I'd like the option of pot-snap/catchup behaviour I know there are strong opinions on this one so to have it configurable would be good. As it is rare for the current actual pot position to line up with the value of the currently selected parameter I find the pot-snap a bit harsh when tweaking live.

I haven't looked at the schematics, so maybe pin count is an issue. But it seems that encoders would have been a better option here...?

thanks

fcd72

Oh no, please not that perpetual "Pot vs Encoder because i always want to have the line on the knob matching the value at the display" discussion......

mokomo

dot, on your second point, you are aware of the Parameter Fetch option?

e.g. you are on Voice 1, with the first pot on OSC (dialled to about 9 O'Clock) setting Coarse to 17.

Then you change to Voice 2 where Coarse is already at 65. 

With Parameter Fetch set to 'On', the pot will only start affecting the parameter value when you dial the pot through 12 O'Clock (i.e. where the 65 is)

nightworxx

Fetch rulez !

dotlogic

Parameter Fetch sounds like the option I want. thanks guys.

Like I said, I've only had a short bit to play with this thing.

@fcd

Pots make sense in some cases, encoders in others. resolution, pin count, cpu time spent scanning etc. are all factors.

But as there is a display, and no one-to-one mapping between pots and parameters, what information does the line on the knobs give to the user about actual parameter values? nothing. So I'm not sure why pots were used in this situation, but I trust it was a logical design choice for whatever reason.

fcd72

...and as the knob position is meaningless i dont look at the knobs in the studio, i tweak them until it sounds ok. For Live performance i use the fetch/snap option which i dislike in a studio context as i everytime think something is broken when nothing happens ;-) I dont lilke Encoders for most cases as i like having the whole parameter range in approx 270°. A good design choice albeit is the MicroWave XT, it has a button if you have a binary choice, an Encoder with detents for quantized parameter ans Encoders without Detent that speed up quite organically with turn rate. But a XT is slightly more expensive.....

dotlogic

I don't think the knob position is meaningless, in that rotating them causes the parameter to jump to an absolute value regardless of the parameters current value and its effect on the sound. But that is why we have software solutions like Parameter Fetch.

All digital parameters are 'quantized' really, which lends to them being easily adjusted using a digital input device (encoder) rather than a physically absolute/electrically analog device quantized by an adc.

And like you say, encoders without detent that use a software acceleration curve are a good compromise for mimicking pots.

Having said all that I don't mind the pots. I get the feeling that well implemented encoders would've worked better for me but they certainly aren't a deal breaker. I just came to question their use as I wasn't aware of the Fetch option. In other words I should RTFM!

Perhaps one day someone will come out with a cheap encoder solution that rivals the resolution offered by the adc's in these microcontrollers. Then we can put this one to rest for good.

fcd72

Seen from a programmers point of view i have to scan the pots (1 Physical Pin) at a rate of maybe 15Hz for a nice response, ill have to scan 2 Pins at a rate of 150+ Hz to make use of an Encoder. Multiply this by 5 for the LXR and you have a rather busy MCU. The MidiALF has 10 Encoders, but its a Sequencer so it has nothing to do while waiting for the next Event to happen....

dotlogic

I'm pretty sure the atmega in the lxr isnt doing a great deal of work. But yeah, I know pots are simpler than encoders. more io, more cpu time etc.

From a user perspective it is down to preference. I'm happy with the way it is. And we could argue back and forth but there is no gain to be had.

shiftr

In ableton live there is another solution to fetch the knobs... It's scales the movement of the pot with the value stored in memory. That way the pot always reacts directly without jumping. It works really nice. I guess you have to check it to see how it exactly works.