easier random function.

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.

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

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!

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!

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.

Hmm, i’m not sure but it seems like patch/program changes already work this way? It seems to me now after playing with this a bit more that program changes are sent in split mode, and the entire patch is sent while polychaining… But I haven’t taken the time to hook it up to a midi monitor to see what is sent, and when.

Are there more details about how this is designed to work somewhere? The manual is a little slim on info in that arena.

are we already able to make sequence only dumps?
this I'd like

for random function: I'd like first to press the two knobs to activate.
But then, as you never only press only once :-D
I'd like to be able to continue the random thing via the main encoder!
pressing again a button takes me back into normal mode to tweak and so one...

I'd like to see the "performance" parameter names and values in the load menue at least or only by tweaking

more modulation slots!!!!!!

I haven't seen this mentioned anywhere but I may be wrong: I have been playing with the arpeggiator a lot recently and was wondering how easy it would be, or if it would even be possible, to have the arpeggio restart from the beginning of the sequence in latch mode when the MIDI notes/keys are re-triggered? i.e, re-triggering the chord notes or playing a different chord in latch mode would restart the arp/seq clock. This would be especially good for live performance when the arpeggio clock does not quite match the drum timing - you can get a better approximation to 'loose' drumming or an unknown BPM by playing the chord at the beginning of each bar which restarts the clock from the first beat.

Also, how about an 'additive' latched arpeggiator mode whereby you play a chord, release the keys and then add other notes to it in an incremental or aggregated fashion (though this may require more than 7 notes in an arpeggio).

.....not sure I'm making much sense..... burble, burble, glug

>> Also, how about an ‘additive’ latched arpeggiator mode whereby you play a chord, release the keys and then add other notes to it in an incremental or aggregated fashion (though this may require more than 7 notes in an arpeggio).

>But then, how do you tell the arpeggiator that “this note should be added to the chord” vs “this note is the beginning of a new arpeggio”?

I admit that hair-brained idea was a bit of an afterthought!

>> to have the arpeggio restart from the beginning of the sequence in latch mode when the MIDI notes/keys are re-triggered?

>Same question as above… What if the arpeggiator is arpeggiating C, E, G ; and you play C, E, A to change the chord. Should it retrigger or not?

My idea was that every time you play a new chord, even if identical notes are played, the clock is re-triggered. I suppose this means that even if you play one note, as soon as you let go and play another single note, the clock is re-triggered. So yes, playing C,E,G and then C,E,A would re-trigger the clock, as long as all keys were released in between the chords. If you played C,E,G, then let go of G, keeping C and E down and then played A, this would not re-trigger the clock. This would allow for the player to bring the arpeggiator into sync with the beat of the music (perhaps the drums) at the beginning of each bar (or as many times as the player wants to re-trigger the clock). This would be particularly useful if you had no way of MIDI syncing to the rest of the music (analogue drum machines and real drummers in a live situation). I imagined an arp+lat+rtg mode but there is probably no room left in the firmware?

If I am the only one who thinks it is a good idea then never mind - I'll give the drummer a kick every now and again ;-)

How about modulation destinations for filter 1/2 decay time? That would let you do 303-style accented bass notes by making louder notes have shorter envelopes.

a|x

@Manuel: not sure that would work very well. What about several simultaneous changes being made from a MIDI controller or sequencer? For example, using the XStation template I made, I can change filter and envelope parameters at the same time. To display these, the Shruthi display would have to switch between several different pages, which wouldn’t be useful.

a|x

I think the way its implemented currently is the best compromise: if you happen to be on the particular page on the Shruthi showing the parameter being edited remotely, you’ll see the value changing.

Incidentally, pichenettes, did you consider making all the knobs endless encoders, rather than pots with a limited angle of travel. This is probably a personal thing, but I’ve always thought that relative operation with endless encoders made more sense with physical controls that have more than one function. Having said that, I haven’t found the fact that the position of the controls initially bears no relation to he value it’s controlling too annoying in practice.

a|x

If you need to fine-tune, you can always us the controls on the Shruthi itself, surely.

a|x

@pichenettes you can relatively easily modify some kinds of encoders to remove the clicks. I’ve got a 95%-completed MIDIbox MB-6582 (long story) that uses encoders modified in this way. Those encoders are much larger though. Not sure if the same trick can be applied to the much smaller units used in the Shruthi.

a|x

There’s no free pin on the ATMega :) And even if there was, you wouldn’t got very far with it. To get a CV/Gate out compliant with what analog synths accept, you’ll need at least a 12 bits DAC to get an accurate pitch CV, and a 9V supply circuit to generate the large pulses and voltage accepted by analog synths.

*whistles too

New Shruthi user here, so I may have missed something, but I would really love to see a down–ramp waveform for the LFOs. I use that way more then the up–ramp wave that's there now.

How would that work for the LFO2 -> filter routing?

@aksmaster. Unfortunately if I decide to save more stuff in the patch, I’ll have to revise the patch data structure and this will break everybody’s patch library ; so I’m reluctant to do that. I won’t do it unless it’s for a very major upgrade.

@cbm. rosch’s solution is the right one. The env / lfo modulation settings on the filter page are just hardwired shortcut – easy, accessible defaults like on the MS20 or ARP2600 :) Note that in early versions of the firmware, the env and lfo settings on the filter page were in the -63..63 range. But it’s easier to kill the modulation when the modulation range goes from 0 to 63 (turn the pot fully counterclockwise), rather than when it goes from -63 to 63 (very precisely center the pot).

here is a complicated feature request that just donned on me

a vocoder to go with the digital FX board

It would be possible to have a vocoder with a single audio input, if the carrier waveform was hardwired to be the osc output from the control board. Doesn't solve the processor problem though, obviously...

a|x

patch the sequencer in to transpose the arpegiator.

@pichenettes Ah, OK. I hadn’t looked at the circuit layout closely enough to notice that.

a|x

Also, and I know this has been discussed, and dismissed in the past, but can I put in another request for MIDI CC control of the 2nd filter in the SVF? Please….

Looking at the chart in the manual, there are plenty of unused CCs, and it seems crazy to be able to tweak the first filter from my controller keyboard, but not be able to touch the second. I know the parameters are probably accessible via NRPNs (are they?), but (and I know i keep harping on about this, but it’s still an issue), the ever-popular and otherwise excellent Ableton Live doesn’t support NRPNs….

Sorry to whinge on about this again. I guess I’m just a bit of a fanatic about being able to control, and sequence everything via MIDI. I know I’m not alone in this though.

a|x