#1

Just wanted to say thanks to @markeats for molly_the_poly. Fantastic sounds right off the shelf. Now I find myself wondering how hard it would be to add MPE to it…

7 Likes
Friends of norns: gear, accessories, etc
Norns: update 181002
#2

It’s really a good one. What’s the spec for MPE? That’s the extended MIDI thing right?

1 Like
#3

You’ll need to create a free account to see the spec:
https://www.midi.org/downloads?task=callelement&format=raw&item_id=165&element=f85c494b-2b32-4109-b8c1-083cca2b7db6&method=download

Here’s the press release:

@junklight has done a bit with MPE on norns, perhaps he will elaborate?

Personally, I’ve landed on the Linnstrument after a fling with a Seaboard Grand.

#4

Cool! It should be very easy to add per note pitch bend (the engine supports it, just needs script tweaks) and per note pressure is already fully in there. Some kind of response that maps to MPE timbre is on my list to add in future. I don’t have an MPE controller to test this stuff out though so would appreciate any feedback.

#5

it was dead easy to support MPE

The only reason I’ve not submitted this is that currently it makes one sound :slight_smile:

The one issue I’ve had was that light blocks seem to crash the Norns - I’ve not figured out why, first theory was CPU but during my investigation I came to the conclusion that the light block sends a weird signal that blows up my patch so it might just be using that physical model.

I do plan to make a proper MPE script one day but time, time, time as ever

(now I’m into grids as a musical interface I’ve got my eye on an linnstrument - however super skint at the moment so it will have to wait…)

4 Likes
#6

perhaps MPE discussions should be in a separate topic, but a coupe of thoughts…

do you think that writing the MPE -> parameter mapping is best done in Lua scripts?

my fear is the more processing thats chucked into the lua main processing loop the more likely we are to start seeing timing/jitter issues occurring. (baring in mind that MPE devices can create a lot of messages :wink: )

my initial thoughts on this , is a better model would be to do MPE processing as a separate MPE device, which could directly (in separate thread) send messages to supercollider - and then to have a simple system (which could be in lua) tells SC which MPE attributes (x/y/z, or timbre/pressure/slide) to map to which synth parameters.

this is the model that I will be following, but this is also because Ive got a Soundplane and a Eigenharps, which have their own process (my MEC application) which can generate either MPE or OSC,

so in my case, its “obvious” that:
controller : MEC -> (osc) -> Supercollider
is better than:
controller : MEC -> (midi/mpe) -> Matron -> (osc) -> Supercollider

on the against side of the argument,
this is ‘inconsistent’ with the current norns model, where the LUA script does all the midi processing,
and this approach is simple and easier for non-developers to adapt to their needs,
and finally @junklight has found this approach is working ok.
I see these as compelling arguments to keep it this way.

but as I said, I will personally go the direct supercollider approach, as for me, the most important part of expressive controllers is their responsiveness and lack of jitter - and it also happens to fit my current model better anyway.

perhaps with careful design the two approaches could co-exist ?!

(obvious note: rPI/Norns is multi core, so threads/processes can potentially be placed on separate cores)

1 Like
#7

+1 from me for a separate place to put it - it doesn’t feel like the lua is the right place for it at all really - although I will be adding in MPE recording to one of the sequencers I am working on and that needs to be considered if it is broken out (all this stuff I talk about will be released but I’ve got so much on the go most at the moment most projects only get a few hours each week - they are all progressing though and one are two are nearly done!!)

I like the idea of thinking through adding in a control convention* to supercollider might make a lot of scripts simpler. It would also mean that people only interested in writing the Lua side would have a lot more functionality from the engines for “free”

*although I’ve no interest in SC engine’s having to implement protocols - one of the really exciting things I want to explore with Norns is to have something generative way outside the current synth/control models

2 Likes
#8

yeah, I think being client/server, theres always room for a discussion on what functionality resides on the server, and what on the client - true for norns (scsynth/lua) as it is SC (scsynth/sclang).

as you say though, the more functionality on the scsynth side, the more ‘conventions’ (protocols/api) there are - in a similar way to the way the norns lua api is extending.

it’s kind of inevitable, if you want reuse, which is of course is only one possible model!

which kind of leads to the next ‘question’ - how generic should it be?

you could bake in to SC how a particular ‘engine’ responds to (e.g.) a timbre message, and consider this a characteristic of the engine, and how it sounds.
or
you could just have a mapping, which says timbre maps to (eg. ) cutoff parameter, but the user can change.

the latter at first seems the ‘obvious’ choice, but is it?

one of the principles of Supercollider is that it is quick to code, so if you want a variation , just code it.
(why build ease of use, on top of ‘ease of use’ :slight_smile: )
this way you can really ‘tune’ the SC code to make it feel right…

also the idea that any parameter can be mapped to any mpe attribute will be an ideal that cannot be attained, for the very simple reason not all parameters will be ‘per voice’ , or may be too processor intensive to realistic alter with continuous control. (so this ‘suitability’ would need to be fed back to lua some how)

anyway not entirely clear to me the ‘best’ solution,
I think my approach (as its close to what i have now) will be to try the direct osc route, and perhaps initially hard code the SC engines - as this is also inline with my desire to have SC as a flexible part of the solution, rather than some black box with lots of layers on it, that i dont understand :wink:

1 Like
#9

In my day job I am constantly negotiating the tension between immediate gratification through one-off solutions vs. long-term growth and evolution (not to mention consistency, reliability, and usability) through generalized approaches (which take longer and are harder to get right).

The answer is almost always “both”.

So, I’m interested in idealized/generalized approaches to MPE, but I’m also interested in (or at least benefitting from) adding pitch bend and y-axis timbre parameters to @markeats molly_the_polly.

Also, I’m pleased and a little surprised to see this little tangent turn into a thread but mostly I just came to say thanks to @markeats.

3 Likes