Physical modeling engine: Ripplerx: lv2 installation pull request & merged

There is a new physical modeling plugin available as linux lv2, open source and gpl 3.0 which is described as inspired by AAS Chromaphone:

It seems to model some behaviour banging on thing onto another (including "9 Models of acoustic resonators: String, Beam, Squared, Membrane, Drumhead, Plate, Marimba, Open tube and Closed tube). Maybe it is a candidate, I wasn’t able to check it out by now.

By the way: are there any plugins of ChowDSP present? The Tape Model seems very good, also the KlonCentaur:

3 Likes

Download from Here

Follow the instructions for linux but DON’T do the sudo apt update line…

Took a while to compile but it’s landed .

Search and enable in the Engines Menu

And the zynthian knobs drive the RipplerX GUI.

The cajon has been looking for a physical modelling thingy for some considerable time.

3 Likes

I’d love to do that, but I don’t know the outcome of apt updating the repos (and other things like compiling). Maybe I should think about a testing sd.

Thanks for trying, it really sounds like banging one thing onto another one.

Really happy to see this working smoothly. It seems like 99% of free (and nearly as many commercial) physical modelling instruments are just another variant Karplus-Strong. This looks like it could get more into the territory that Tassman covered before it was discontinued.

K-S is fine but it isn’t going to give you the sound of a flute-timpani-cello-gong hybrid.

how to do it? could you teach me?

I read:

linux

sudo apt-get install libx11-dev libfreetype-dev libfontconfig1-dev libasound2-dev libxrandr-dev libxinerama-dev libxcursor-dev
cmake -G “Unix Makefiles” -DCMAKE_BUILD_TYPE=Release -S . -B ./build
cmake --build ./build --config Release

but I do know know where to do it?

I am not aware how to do it as well, but typically you would log into your zynthian via ssh, the webconf terminal or directly with a keyboard connected and the zynthian service stopped.

I would anyhow wait until somebody really knows tells you, because I read that updating (sudo apt update) repositories on zynthian may cause trouble because things might rely on older versions of installed packages. (Although nothing which wouldn’t be managable by burning a new sd afterwards or just burn a second sd for testing purposes)

I didn’t do the sudo apt update.

Everything else was just copied into an ssh terminal on the machine.
The compile and cmake took about an hour.

It’s conducted outside the zynthian infrastructure so green heart is unaffected.
I’m effetively testing it in day to day usage, but I’ve not seen the Xruns or associated problems you see when things do go wrong. I don’t know if I’m considered as someone that really knows but I am aware of the risks and backup up the machine before I started.

1 Like

1/ Backup zynthian using webconf system

1.5/ Have you backed up???

2/ Log onto the zynth, with a ssh terminal. You could possibly use the webconf terminal but I prefer not to, which is probably little more than prejudice.

3/ you should be in the /root directory. Type pwd to find out.

4/ type git clone --recurse-submodules https://github.com/tiagolr/ripplerx.git This will download the RipplerX source code into a directory in /root called ripplerx. This is going to be compiled to run on your specific hardware.

5/ type sudo apt-get install libx11-dev libfreetype-dev libfontconfig1-dev libasound2-dev libxrandr-dev libxinerama-dev libxcursor-dev ,

as one line. This loads in the dependencies required and is a possible source of problems if they are to occur if there is a dependency mismatch, but it worked on my Vangelis based machine, so it has been done successfully…

6/ type cd ripplerx

7/ type cmake -G “Unix Makefiles” -DCMAKE_BUILD_TYPE=Release -S . -B ./build

8/ type cmake --build ./build --config Release

This will, if it completes, and it should eventually do so, install and compile the software.
THis means that it will be visible to the zynthian engine tool that scans known places looking for lv2 components which you have now created .

9/ Go to the webconf software engine display and type rippler into the search window press the search all button.

10/ after a period of time the ripplerX component should be displayed

11/ Enable ripplerX

12/ You should now find it as an engine in the synth category, and you are good to go…

Don’t forget to backup before you start.

2 Likes

git clone --recurse-submodules https://github.com/tiagolr/ripplerx.git ?

One question: Does the compiling process max out the cpu usage of the Pi? I’m still testing cooling performance in my build inside a wooden case and wonder if it stands a one hour compiling session.

Didn’t seem to. It was a Pi4 ( rack6.local my main home machine) I played the occasional note with Mimi’D whilst it was all going on and the the compile certainly maxed on one processor

Why not to add it to Zynthian instrument engines?

Simply make a request, with the Report Issue button in webconf.
The Gods will decide.

There is always a chicken and egg situation with something like this, in that somebody really needs to test it first to prove it’s worthy.

To test it, we need to load it in as many places as we can and see if it behaves, then post up some audio files as proof and demonstration of the noise it makes.

Once we’ve done that we start to consider refinements we make to address any limitations we find.
Particularly in this case the naming, grouping and ordering of Parameters which is alphabetic ish . . . The GUI has some structure which it would be beneficial to match in the parameter layout.

Personally I don’t know how we do that level of manipulation, but I’m sure it’s somewhere in the zynthian infrastructure, so I get to examine somewhere else.

It’s all rather theraputic really. . .

Yes that’s it. Discourse is a little too keen to be helpful on occasion …
Thanks for a solution to the problem

:grinning:
:grimacing:

I would like to know that because it could be a meaningful way for me to contribute to the project somehow by writing some more aligned controller pages.

I looked into the code (I don’t speak python actually) and have the impression that the general creation of controller screens is done in zyngine/zynthian_engine.py, more specifically for LV2 plugins in zyngine/zynthian_engine_jalv.py each in the plugin_ctrl_info = {} command, while zyngine/ctrlinfo/ctrlinfo_Osirus.py would be an example how to change controller and control pages order for one specific plugin.

Don’t worry they are small petty gods, and it’s all turning into swans, thunderbolts, krakens, maidens and strange stuff like that, most of the time…

Frankly the whimsy is palpable . . .

The lv2 file format has a manifest file that points at a name value pair in a tml file (I think).
I don’t know where the or how a base mapping is generated but I’ll have a look. Given there are discussions elsewhere about groupings, albeit about chains, it’s obviously something that the success of the overall approach has dumped up on the tide line for us all to contemplate.

Personally I think we are at the stage of supplying differing orderings, so you could align the Parameters alphabetically, forward and backwards, by usage, by groups, by some form of editing function, popularity or defined files that can be loaded and saved and passed around where lives are cheap and well turned snapshot decides a man’s fate.

Grouping ADSR’s have been discussed as a result of MiMiD but that sort of alignment was recognised.
Discussion is the first step, and then we can play with branches, and back to the mercy of the diety’s that watch our every move.

Definitely. A suggestion (draft) can be considered as a contribution to the discussion I hope. As far as I can see Osirus is the only LV2 engine with a custom controller setup. I think alphabetically (forwards/backwards) or the original param id is an appropriate fallback option, but any custom layout might be an advantage. Having the synthesizers OSC Waveform on page 248 of 410 (which is far behind “Effect #27 Param 259”, which starts with “E”) because it starts with “O” is debatable.

There are some phrases that could be recognised. Pulling everything called Osc1 … into a similar group would be beneficial, along with ADSR but, the most effective way would be to have easy passing of a suitable mapping that could be propagated.

Perhaps the categories could supply a base grouping on the basis that delays will have similarly characteristics and synths generally use the same sort of nomeclature.

Well warn paths basically.
Favourites can also help a fair bit.

I’ve done similar things in big data sets and making the ordering mechanism easily configured and displayed is a requirement to ensure it actually gets used. People can easily get into confusing orderings and then lack an easy way to get out of the feature, and that spreads a reputation for complexity. One only has to look at github and it’s semi search language for reports to see how this can become intimidating.

Another GUI consideration, but one that want’s optomising in the several cases where it is going to become a necessity.

Seems that ttl in zynthian/zynthian-data/lv2-custom/ are involved, I have to investigate further…

OK @zynthianers!

RipplerX is now available in vangelis (testing). Simply update and enjoy!

But i need some of you pay the little price for so good & fast service:

I mean, RipplerX is a super nice physically modeled synth with a warm and deep sound. It deserves a full integration with zynthian UI, and this requires a volunteer write a custom TTL adding the parameter groups and envelope (ADSR) designation to the right parameters.

This should be done by editing the original RipplerX’s dsp.ttl file:

dsp.ttl (15.2 KB)

You can find a lot of good examples in the zynthian-data/lv2-custom folder:

zynthian-data/lv2-custom at oram · zynthian/zynthian-data · GitHub

As soon as this task is done, i would add the:

AnalogTapeModel

that also seems so interesting :nerd_face:

Regards

2 Likes