Linnstrument firmware: possible to shape attack with pressure?

[NothanUmber]

Trying to understand whether it would be viable to shape the attack curve "MPE+-style" via pressure instead of velocity+envelope.

A lot of factors seem to go into this. This is what I could currently understand from the code:
* when using the USB interface it uses 115200 baud
* the default MIDI minimum interval is 235 microseconds
* by default it waits midiMinimumInterval * 34 = 7.99 ms between sending the same message type on the same channel again (so this would apply as pause between pressure events on the same channel)
* between any two midi messages we always wait midiMinimumInterval * 3 + X (where X is 2 ms in the case of a note on or note off) = 705 microseconds | 2.7 ms for note on/off
* these default 235 microseconds MIDI minimum interval can be changed via Nrpn 252 in an intervall [0;500]
* additionally the default MIDI minimum interval can also be overwritten by a value read from the flash (don't know which value is stored there)

Is this understanding right? What would have to be changed when trying to shape the attack with pressure? I guess the hardcoded 2 ms "forced pause" after note on might have to go? And assuming we can send 115200 / 10 / 6 = 1920 14 bit midi events per second, and lets say we allow 5 simultaneous voices, could the midiMinimumInterval be set to 1 / (1920 / 5 (num voices)) / 34 ("magic" number) = 77 microseconds then (so we could shape any "manual envelopes" with 384 values per second - or 128 for xyz in parallel)?

[Roger_Linn]

Thank you for all the coding details but I'm confused about your musical goal. In musical terms, what are you trying to achieve that can't be achieved now?

[NothanUmber]

The idea: Having more manual control over the attack by shaping the attack curve with the finger instead of via an envelope+velocity value.
It also seems to be the assumption the current presets of the EaganMatrix make (on first sight Linnstrument and ContinuuMini share a lot of properties, particularly regarding y range - so with the velocity vs pressure thing out of the way it might be possible to share presets almost unaltered (perhaps with some slight adaptions regarding pressure mapping). Essentially the Linnstrument could be seen as eight vertically stacked, polyphonic ContinuuMinis )

Conceptionally it is clear that the manual approach allows more variation in the envelope shape than the auto-envelope. (Of course the automated envelope could be programmed to replicate any particular manual envelope. But it would need more than the one available velocity parameter to determine which automated envelope to use - whould it be linear, more logarithmic, exponential - or any arbitrary shape)

It would be interesting how much difference in velocity+envelope vs manually shaped envelope really can be heard or "felt" of course. To find this out one would probably have to make an A/B blindtest comparison with the same instrument that supports both variants and a switch between two presets, one with classical automated adsr attack and the other with pure pressure...

[Roger_Linn]

I think you're discussing the same thing we discussed on the forum topic "MPE+ support feasible?", correct? In other words, your musical goal is to not use an envelope generator but rather to use pressure only for continuous note loudness, thereby controlling envelope entirely with finger pressure. In other words, a hard hit produces a sharp attack and a slow press produces a soft attack.

If so, then I have nothing new to add to that discussion. To recap, if a synth slews volume or filter frequency as they all do, it doesn't matter how fast your pressure messages are because the synth will slew them. If you want a fast transition in synths, you use an envelope generator. If a synth were to sense fast pressure transitions and not slew those, you'll get the sharp attacks you desire. Currently if you strike a LinnStrument pad fast and with high force, you'll get an instant transition from zero pressure to 127 pressure, which synths will slew. So the problem is not in LinnStrument but rather in the synth's slewing. So perhaps your efforts would be better directed to your synth maker of choice.

[NothanUmber]

Afaik EaganMatrix is not slewing these (at least slewing can be controlled), Madronalabs stuff neither (at least in T3d mode), nor EigenD. If Linnstrument plays nice with EaganMatrix this could be *the* standalone combo.
So the synths are there, so I gently knock on the door of the instrument makers

But thanks for making the Linnstrument firmware open source. If my use case is considered too esoteric I can at least experiment a little on my own.

P.S.: Not to be misunderstood: Linnstrument default settings are really great and make a lot of sense. (In USB mode it uses several times the throughput of default MIDI and - if I'm not mistaken - can blow out 125 14 bit e.g. pressure values per second and voice. Which few other MIDI or MPE instruments can.
The settings proposed above are mainly a trade off - getting rid of the several ms pause after note on (which makes sense if an adsr is used), sacrificing some polyphony (from 16 down to 5) for even higher timewise resolution (from 125 up to 384 values/s - which makes better use of the nice, low scan cycle time the Linnstrument offers. Could probably go even higher - at the expense of further voices or going down to 7 bit midi resolution). Both settings imho make sense for their respective use cases.

P.P.S.: Think I overlooked something in the calculation above: When I divide the 384 values per second that we could get for just 14 bit pressure and 5 voices by 3 (for not only z but xyz - so pitch bend , modulation and pressure) then we are basically at the ~125 values/s that are currently configured. So the current configuration seems already be highly optimized for (almost) maximal time resolution possible. (As far as I understand the current settings already assume either five 14 bit voices or ten 7 bit voices - which sounds realistic.)
So the only things that could still be done is making the currently hardcoded note on latency configurable. And perhaps introducing some heuristics that favor one event type over another (e.g. allowing the full scan cycle 500 values/s for pressure and pitch bend of the last played note and distributing the remaining bandwidth for the other events and voices). But this (being a tradeoff again) would require some experimentation.

[BobDog]

I'm interested in this as well as I will be getting a Conituumini.

One thing I am wondering is if it is possible to increase the speed up above 115200.

I have got an Arduino Due setup somewhere with uses the USB Midi code (I can't remember the one the Linnstrument uses, I will have to find it again) so could experiment with upping the speed, if I get some time that is!

[NothanUmber]

Great!
Found some interesting article:
https://copperhilltech.com/blog/how-to- ... unication/

According to that 230400 seems to be in the cards with the current approach and some tricks.
More interestingly there seems to be a "SerialUSB" library specifically for Arduino Due that allows to use USB 3 at full speed, not RS232 emulation mode. From what I get from the docu the MIDI class profile isn't limited to "original MIDI speeds", so full speed USB+MIDI class compliant profile could be the holy grail regarding bandwidth on the existing hardware:
https://www.usb.org/sites/default/files/midi10.pdf

Take all this with a can of salt, just starting to wrap my head around this...

Question is whether synths like ContinuuMini can cope with that amount of MIDI data on the external interface. (Internally it is afaik running at 700 us refreshrate - so up to 1400+ xyz vectors per second and voice. (And as it is the same chip as in the big Continuum it should be able to even cope with 3000+ xyz vectors per second for up to 16 voices). But the scanning and EaganMatrix seem to be running on the same chip, would have to be seen how fast it can read from USB). But "as fast as the synth allows" would be a luxury problem then, if we could really get the full (I think 500 Hz?) scan rate of the Linnstrument on the floor then I think the limiting factor are the reactions and senses of the person sitting in front of the instrument

[Tj Shredder]

If we could really get the full (I think 500 Hz?) scan rate of the Linnstrument on the floor then I think the limiting factor are the reactions and senses of the person sitting in front of the instrument

This is true anyway. I think in terms of me controlling the aftertouch consciously I am a lot slower anyway. And the only point where I am faster is the attack. But in my mind its different, I just hit as hard or soft and do not perceive it as pressure...
The only thing one could think about is that before the velocity is measured one could send out aftertouch already. If I understood that correctly that is what MPE+ is about in essence. But this would only be usefull if the synth could respond to it, or if you build your own in Max/Supercollider or in hardware...
The lag isn‘t that bad at all what we have now. So I am with Roger here... But I would encourage you to dive into the firmware and do your own experiments - the more people know the firmware the more interesting ideas will cook up...

[NothanUmber]

If we could really get the full (I think 500 Hz?) scan rate of the Linnstrument on the floor then I think the limiting factor are the reactions and senses of the person sitting in front of the instrument

The only thing one could think about is that before the velocity is measured one could send out aftertouch already. If I understood that correctly that is what MPE+ is about in essence. But this would only be usefull if the synth could respond to it, or if you build your own in Max/Supercollider or in hardware...
The lag isn‘t that bad at all what we have now. So I am with Roger here... But I would encourage you to dive into the firmware and do your own experiments - the more people know the firmware the more interesting ideas will cook up...

Yes, MPE+ sends out a note on with constant velocity 127 as soon as they have measured the initial-touch x/y position (so they don't have to wait until they have gathered enough pressure values to calculate velocity). And then use pressure events to shape the actual attack envelope.
Regarding lag: From my understanding of the code it should be about 2 ms "extra note on delay". But when measuring the time between note on and the first aftertouch event it were 10-12 ms or so - which is noticable, particularly as it's non-constant. Have to better understand why this happens.
You don't have this problem when going with velocity+envelope for attack so it is currently the better solution.

[BobDog]

I'm interested in this as well as I will be getting a Conituumini.

One thing I am wondering is if it is possible to increase the speed up above 115200.

I have got an Arduino Due setup somewhere with uses the USB Midi code (I can't remember the one the Linnstrument uses, I will have to find it again) so could experiment with upping the speed, if I get some time that is!

I think this is what they use: https://github.com/radikalbytes/dual_boot_Due

[pdxindy]

Afaik EaganMatrix is not slewing these (at least slewing can be controlled), Madronalabs stuff neither (at least in T3d mode), nor EigenD. If Linnstrument plays nice with EaganMatrix this could be *the* standalone combo.
So the synths are there, so I gently knock on the door of the instrument makers

That is a couple of esoteric synths... the other 20+ MPE capable synths currently available in regular VST land don't do this.

I'm not arguing against it... just that it is already taking plenty of time to get just plain old MPE implemented. Also, there are other improvements I'm just as interested in seeing developed in the various MPE capable synths available. Such as curves and limits on mod ranges.

I recently purchased the 1/2 size Continuum. It is definitely more expressive on the initial attack. It is going to take some effort on playing technique though. So far I'm finding it challenging to play quick sharp attacks for example. There are various sounds I would rather use the Linnstrument.

The surface of the Continuum is so dramatically different than the Linnstrument. I'm not even sure it makes sense to try and make the Linnstrument behave like the Continuum.

[NothanUmber]

Think the Linnstrument and the Continuum will always retain a unique personality. Different surfaces, different layout.
Think sequencer trigger, arpeggiator trigger, purely velocity based, velocity+aftertouch, velocity+channel aftertouch+modwheel, velocity+poly aftertouch+per finger modulation, no-envelope-full-finger-control-xyz are just different steps on the automation vs manual control ladder.

And in each category you have sounds that work best with that control scheme. Imho playing a piano sound with pitch bend and modulation just because you can is... at least not mandatory.
Some cool arpeggiated sounds sound cool mainly because of the cool (potentially otherwise unplayable) arpeggio. And a drum sound doesn't need 3d modulation.
So imho manual control over attack isn't rendering every semi-automated control approach obsolete.

Auto-evolving sounds can be great. But I am also fascinated by being able to get gazillions of nuances out of a simple "at your fingertips" saw+filter combo. And having manual control over the attack envelope is one further step in that direction.
No plans to take any functionality away from the Linnstrument - the current feature set makes a lot of sense. If a mode optimized for velocity-less play can be integrated without breaking anything else it would imho be a worthwhile enrichment of the palette of available colors.

Wouldn't it make more sense to learn to paint with the available colors before trying to put effort into adding new ones - and just take a thing as it's intended to? Good question, probably a good recipe for the majority of people to get most fun out of things. Must be my curse that in sight of the available I immediately tend to fantasize about potential possibilities

[BobDog]

Hats off to anyone that wants to change the linnstrument, it's open source so go for it.

I can fully understand why Roger wouldn't want to changes things when there are financial reasons not too though.

[rlauriston]

If the goal is to swell from zero, can't you do it similarly to the way you can on a Prophet T8, by (if I remember right) setting the attack, decay, and sustain to zero, and modulating the amplitude with pressure?

I've been meaning to try that but have been distracted by technical problems.

[NothanUmber]

Yes, should be possible. (Though afaik the current firmware isn't optimized for this scenario (see posting further up) - but most probably could be).

P.S.: Good news: Both Voltage Modular as well as VCV consider to add "poly cables" (that can bundle up 16+ mono cables). These should be great for this scenario, as both work with audio-rate-modulation of everything with everything. So no (high amount of) slewing etc. to be expected, no hardcoded ADSRs etc. These should be great experimentation platforms...