I’m experimenting with the Striso and FaustIDE in midi. While it’s easy to map “Note on”, the more complicated aspects like “Channel Pressure” are more complex. Has anyone done any work in this direction I can piggyback on?
-Frank
2 Likes
No, but I will be eager to piggyback on what you work out! 
Please keep us posted!
1 Like
After a few fruitless sessions I reached out to the folks on the Faust mailing list. The short answer is that you can’t. You can target Faust on something that does play nice with MPE. Their suggestion was JUCE.
Given what I really want is something I can tinker with in real time then put onto hardware, I’m looking into using the Organelle with @thetechnobear 's Orac which, in principle, should be able to handle MPE. I’ll do experiments in the near future and keep fellow tinkerers posted on the results.
-Frank
I think the important question here is… what are you tying to achieve?
really, I’d use faust mainly on the audio/dsp side, rather than using for a voice architecture/midi implementation.
Id say that thing like pure-data is a bit more ‘complete’ in this area (though even they are not necessarily ideal)
but also you talk about striso and mpe, so I guess you are planning on running the ‘synth’ on some additional hardware… does this mean on your computer? or something else?
as for Orac, indeed Ive added some MPE support, but honestly few use it, so I think for some its a bit hit n’ miss… simply because there is no standardisation modulation matrix (for mpe), as few use it, when I need to modulate something differently I’ll often just write a new module (or adapt an existing one)
… easy for me to do, but perhaps more difficult for others?!
on a computer, you have a ton of options these days for MPE support, everything from full synths, to modular (vcvrack) , or if you want to ‘diy’ things like MaxMSP are good now.
with so many options, really its all about goals, and also (importantly) how much time you want to invest in creating something for yourself.
1 Like
Hi Mark,
Thanks for the thought out response.
The (current) target is:
- To use more complex wave forms than are on the current default configuration for the Striso. (I’m a fan of more ‘strings’ sounds myself)
- Add minimal extra hardware, mostly for portability concerns not cost. When I want to play it’s either when travelling or in a filk circle.
- Get creative with how it’s responding to inputs, my current thoughts (some based on @pierstitus’s original paper):
- Add ‘plucking’ to it, where it picks up that the motion on a button is primarily on the y-axis and makes an tone with a long decay on release.
- Being able to change sound by waving it around in the air is of minimal interest to me… Having it act like a percussion instrument when you slap the top on the side would be handy.
- (minor but growing) I’ve had fun playing with the audio/signal processing while trying to get this to work in Faust and would probably like to keep tinkering.
While for point 2 the dream would be to put it all on the Striso itself, my skill in Faust is weak enough that to get anything done takes a lot of tinkering, and the work cycle for writing, compiling and loading on the Striso isn’t fantastic for a guy who gets half an hour here and there to fool with it.
The Organelle M looks like it would fit all of these points well, particularly where it would replace the speaker/power bank I currently carry around. But I didn’t want to fork over $600 to find out that it would only ‘sort of’ do the job.
I’m a reasonably skilled coder (enough that I’ve managed to convince people to pay me to do it for the past 15 years). But I have minimal experience working with audio/signal processing. I have access to both a Linux box and a Windows box with WSL. Is there a reasonable way to use Orac on the computer to prototype out the plugin before purchasing an Organelle, or do I just have to cross my fingers and make the leap?
Thanks again,
Frank
I’ll comment on the last point, first as its easier !
Orac, can run on either a Mac though I dont really support this … but you are free to build it.
(this is how I do development for it ) - it can also run a rPI , so thats a cheap option.
the ‘issue’ with both these approaches is really how to control it…
the beauty of the Organelle, is that it’s a standardised interface, so can work ‘out of the box’.
whereas something like a rPI, you’re going to have to mess with it, and start mapping CCs to parameters, using a web browser to configure it… its really not a lot of fun if Im totally honest 
I ported it to the rPI really for a very different use-case to what most try to use it for, so there is a bit of a mismatch there.
I also wonder if this is really the best route for you… indeed it kind of satisfies (2) , but as you say ‘ideally’ you’d like to run it on the striso, and this route would not really take you that direction.
SO…
what would I do? … if it were me and had a striso?
I think my primary objective would be to create something that ran ON the Striso.
the fun of a standalone instrument is hard to beat…
if thats the objective, its kind of important to work to that end, since the striso will have limited cpu processing (I can’t remember what chipset it uses… STM32F4?)
as you say prototyping on a desktop is still very valuable…
unfortunately, it could well be that different tools are going to be required to do this.
a) developing DSP skills
using a high level language to develop your DSP skills, and your ideas, then ‘converting’ this into something you can use on the Striso.
and I’ll be honest, unfortunately, I suspect MPE may be more a ‘distraction’ in this regard.
for example, you could ‘play’ with DSP using things like supercollider/pure data/faust on your desktop, even without MPE… (or use MaxMSP which actually has pretty good MPE support)
get a feel for the sound/instrument you want to create…
essentially, you can even kind of do this with ONE voice… aka the DSP.
in parallel to this you can learn what it takes to create new firmware for the Striso.
b) building the existing firmware, and tinkering with it is a good way to start.
there is likely a learning curve on this one, as you have to get used to setting up dev environment for an embedded target - but once done its surprisingly easy to build/deploy firmware.
c) investigate dsp libs
once you have that done, you can start to look at open source projects that support STM32F4 (?) or just ARM targets… there are quite a few dsp libraries you can try these days
e.g.
these are in C++, which whilst mind seem ‘harder’ (than say faust) will actually be easier to integrate into the existing striso firmware.
and you’ll be surprised how simple some are to use.
again, the tricky bit is usually working out how to set up a dev environment to make them work.
d) integrating …
now the fun/rewarding bit.
doing (a) you will have built up some ideas of WHAT you want to build, and generally got a feel for dsp coding.
whilst (b), you have learnt about the existing striso firmware… and how it handles events, and turns these into voices … i.e. how does it integrate DSP code with the mechanics of pressing keys etc.
and whilst you did (c), you started to learn what dsp blocks were available, and how they relate to (a).
now really its just a matter of replacing the existing synth code in the firmware, with something similar from the dsp libraries.
TIP: do NOT be too adventurous to start with, small baby steps all the way will get you there…
whilst we all naturally day dream about what we want to achieve, starting on an ambitious project will almost always fail… and just be frustrating.
try to only start things you can already imagine how to complete when you start.
… even these limited goals, will still provide plenty of challenges !
… and of course, each time you complete something, you’ll feel great (even if its a simple sine wave synth!), and be ready next time to do something (slightly!) more ambitious, or even just ‘evolve’ what you have to something (slightly!) more complex.
that is the way personally Id approach it !
the alternative is as you say do something on a rPI…
this could be done at a much higher level , and indeed help (to some extent, with (a) above)
honestly the issue is I don’t think any dev platforms on the rPI have ‘good support’ for MPE.
its always a bit clunky… (which is what you found no doubt with Faust too)
sure, you can get it work, but its hard to say its ‘supported’ (even PureData/Supercollider) out of the box, you just have to ‘handle’ it yourself.
his is not that hard, but the issue is there are few examples to build on, so can be a bit daunting when you are also new to that dev environment.
the good thing about using PD or Supercollider is you can also run it on your desktop, as well as the rPI.
It’ll also teach you, how much more powerful your desktop is, and so rein in your ‘expectations’
which to choose? well PD is no definitely easier… and if you like GUI type it works well.
but I personally think supercollider is more powerful, and I actually find the whole gui dev of PD/maxmsp clunky for larger projects) … but learning supercollider is quite a challenge.
there are also things like SonicPI which are a layer on top of Supercollider.
honestly, with a lot of this, you can do it in many different ways… and really the trick is to just get ‘stuck in’ and try it. programming is learnt by doing… making mistakes, fixing.
and prevarication is probably our biggest enemy.
as I say, my main tip is… just start playing with different things, and have modest goals, limit your expectations.
I can say categorically, the most common mistake I see people making is dreaming of wonderful synths, and setting out to create this, and just getting terribly frustrated when (inevitably) it turns out to be much more complicated.
as I said there are quite a few pieces to this puzzle… so just enjoy the ride of learning about all these different pieces.
but hey, as a programmer, you already know this… as you know how when you get started even the simplest things can prove challenging, and you have to start simple!
1 Like
Thanks for the extremely detailed response. I agree on your facts on every point, but end up with different results for my own case.
As you say, working with unfamiliar tools in inherently hard. Two things become a priority.
- Make your early attempts modest.
- Remove as many obstacles as possible.
Sadly, while I’d love to have Striso as being an entirely standalone, the processor (STF32F427) is basically a abacus powered by a hamster wheel. For comparison the Raspberry PI zero gets a CoreMark rating of ~2000. The Striso’s processor clocks in at ~600. I have doubts if my end goal is even reasonably possible on it alone, and if it is then there would be substantive obstacles.
For those who do want to take a swing at that particular hard problem. I have downloaded and built @pierstitus’s source. With a reasonably configured dev system on Linux it was about an hour or two’s effort and I was able to compile it and drop it on my Striso with minimal effort. If you’re a low level hacker, this is entirely doable. Looking at Pier’s code it looked like he was already doing some moderately tricky things in Faust, and I suspect it was to get it where it is within the above hardware restrictions.
So, for hacking on making baby steps to the solution to my big problem I think I’m just going to bite the bullet and pick up an Organelle and start breaking the problem into interesting & manageable bits.
I agree that doing large work in graphical languages gets ugly fast. To do anything of even reasonable size takes some serious dev discipline, breaking everything into small functions(patches?). But since there seem to be a variety of ways to use tools that aren’t strictly Pure Data that shouldn’t be an issue. Some lunatic even rigged it so you could use SuperColider.
So, Day 0, I’m working through LWM Music’s classes on Learning Synthesis with Pure Data. Once I have a reasonable familiarity with the tooling, then take a long hard look at your work and try to figure out how read the basic MPE data off of the Striso.
As soon as I have anything even remotely interesting, I’ll be sure to share it out.
-Frank
1 Like
Cool sounds like you have a plan 
Btw: dont discount the stm42f4 too quickly, I had a lot of fun with one in the axoloti … its surprisingly powerful as an embedded cpu.
( it’s also used in quite a few eurorack modules)
For sure, not as powerful as a modern rPI, but still useful
Anyway, as long as you find a way that you enjoy to work that’s all that’s is important.
Have fun.
1 Like
The Strso board 2020 model has the stm32h7, which is quite a bit faste. The faust speed tricks date from the time when it was running on stm32f4, but still make sense I guess.
For playing with the faust code it’s easiest to use the OSC bridge that’s in the the the ‘tools’ folder in the firmware source. It can be run on linux with the ‘stribri.sh’ script. I didn’t use faust IDE personaly, but I guess it’s possible to enable OSC support easilly.
(I couldn’t answer quicker since I’m currently traveling)
2 Likes
Just a bit of an update. I’ve been working on getting my head wrapped around PureData for the past couple of weeks. While I agree with @thetechnobear that it’s likely to get cumbersome for large projects, it is fantastic for exploratory coding. The combination of very immediate visual and audio feedback to changes and a stunningly good help system(every component has built in live examples of how it works) is really hard to beat. When I have something Striso specific and working I’ll start a new thread for it and share (and hopefully exchange ideas to improve it, DSP really is not my field).
And, as a side effect, I’m pretty sure it can all be done in midi through Faust. Being a newbie on the subject I didn’t ask the Faust group the right question. While there is no pre-rolled MPE support in Faust, Faust’s midi support has all the components you need to roll your own in Faust. From there it’s time and knowledge. When I’ve put together enough general understanding I might circle back to it if no-one beats me to it.
1 Like
Faust has a number of helper tools for generating code for a few embedded environments. The two I know about are Teensy and the Electro-Smith Daisy. The converters generate C++ code, which you then need to integrate into the developer toolchain for the embedded device.
By the way, the Daisy also has tooling for converting Pure Data patches to its tool chain.And if you’re up for spending some money on a single-board computer, the Bela also can run Pure Data patches.
I have a Teensy and a Daisy; I haven’t done either Faust or Pure Data with either of them yet, though. I also have a Striso board on order.
1 Like