Features request for next firmware versions

No I won’t listen to any new feature request for v0.92. Let’s test and deliver it!

Every new feature request will be considered for v0.93

I can’t find mention of it, but I’d love ‘fine’ to be a modulation destination for a single oscillator, so that a subtly modulated osc can beat against a steady osc. It’s a good trick for string synth stuff. The current osc1/osc2 destinations are a bit coarse.

Yes, cc out sounds tasty!

And bump for my proposed arp mode that no one commented on at all! :stuck_out_tongue:

+1 for cc out as modulation destination

+1 CC out!

Have we ever talked about CC out as a modulation destination? It would be cool to have some periodic cc controllable by the lfo or sequencer or to be able to use the 4 cv ins to control other gear in the chain…

Thanks for the answers, I really didn’t notice that there are already *2, /4 and /8 modes, because the steps are so tiny you have to use the encoder instead of the pot to select them. D’oh :slight_smile: If its not a big problem, additional *3 and *6 would be funky :slight_smile:

Of course. There are 16 steps per bar already without any tempo multiplication. Sorry for confusing things.

easier random function.

How can this be made “easier”? A description of the requested behaviour would be helpful!

Okay, maybe i am getting it wrong, if i’m in Browse mode (or combo) and hit the random function everything works as wanted, but i can’t save the actual
generated patch. In order to achieve that, i need to go to save mode first and then do randomization then entering the name. that’s a bit tricky.

For the feature requests:

  • controllable functions by the controller, e.g. MMC (midi machine control), e.g. start and stop of sequencer, midi clock follow (let’s say if you stop the sequencer
    and want to restart-it, then hitting the button would restart the midi at the next main step)
  • Joystick controller (or documentation thereof) for one or multiple joysticks.

Can’t the joystick controller be done with MIDI?

well. probably with some addon PCB, yes. i thought if that’s similar doable as with the programmer.

I wrote this in another post but here we go. I would
like the filter envelope amount to be included in the
modulation matrix. Sometimes (quite often actually)
it feels more natural and sounds better to modulate
that instead of the filter cutoff.

Longer envelope stage times please. It’s okay at the moment while it’s mono but for poly-Shruthis 6-8 seconds for A,D or R isn’t enough!

Note gate as a modulation destination (over 63-> on, under 63-> off)
Sample & Hold as an modulation operation
Playing with the chaos, these would open all kinds of more melodic avenues

a third envelope… with a DAHDSR curve… that can cycle like an LFO… with adjustable slope shapes for both rise and fall :slight_smile:
I realize this would break preset storage, but it would be all kinds of awesome.

Actually, I should’ve said Sample & Hold as a modulation destination, since the lfos laready have a s&h waveform - which samples the noise generator, I guess? Also, I’d like BPM as a modulation destination. I’d really like to have an LFO shift the arp/seq speed between the MIDI clock multipliers. :D.

I guess those features are a bit extreme, but all the basics are completely covered already.

Also, I should’ve said “please”. And “thanks![](”. Because you rock)

+1 for longer envelope times…i like sounds that take time to evolve :slight_smile:

I would overhaul the way that MIDI out works for chaining purposes. If we could generate MIDI clock from the master device, slaves could set BPM to ext and arp/seq modes would be sync’d. I wonder if that’s too CPU intensive. I also realize that it would be problematic if slaves down the line are generating their own clock (not set to EXTERNAL) - how do you know whether to forward the clock received or the clock generated?

Also, in the standard chaining mode, it makes sense to send all parameter tweaks (and the entire patch, on load) over the MIDI out so that the slaves follow the master. In split mode, this is not desirable - it’s usually going to be the case (I think) that there are different patches for each split. MIDI clock would be useful here as well, but what I don’t know is whether it would be advantageous to send program change messages instead of the sysex patch dump. In that case, you could have different patches set up for e.g. shruthi #1 program 1, and shruthi #2’s program 1. When you change the master to program 1, the slave’s program 1 automatically loads, but they’re different patches.

As it currently stands, you’d have to change your program on the master, and then change the program on the slave. The benefit I guess is that you don’t have to worry about keeping patches stored in the right place so that the split configuration is always as you want it. Fortunately with larger patch storage comes greater freedom with this kind of thing.

It might work better to have a slave ignore CC/NRPN messages rather than stripping them from the MIDI out of the master. I think this would work better because then messages can still be forwarded down the chain.

I know that currently the MIDI implementation is as elegant as it can be for polychaining, which is already a complex feat. This would make things a little more difficult to comprehend but I think it would make chaining more useful.

@ pichenettes & janavolt re joystick

Wavestation implements this a 2 CCs +/- 64 in value for the xy. I simpy use my novation remote touchpad to control it instead of a joystick and it works great…