BUT, first you need to turn on the OSC and the fill a port number in option of Surge via the graphical interface. So I need to get into the CLI of this process:
AFAIK, zynthian shouldn’t connect the plugin in this way. I will try to fix it in the zynthian side.
Anyway, it would be nice to have the plugin compiled with just stereo output.
Regarding LV2 presets
I’m testing the LV2 presets generated by surge at build and i think it’s totally OK to use this kind of “fake presets” for factory presets. It has the advantage that loading is super-fast and you can scroll the list while the sequencer is playing to search for the sound you are looking for. Anyway, the generated presets for the 3rd party collection is not right and all of them have the same “RANGE ERROR” name. This should be fixed.
Another way would be converting the native FXP format to LV2. FXP is not difficult to parse and we already have example code for converting OBXd’s fxp presets and others.
Heya thanks for sharing changes upstream. We are planning a 1.3.2 release in next fortnight so please do let us know if there’s any other changes you find or need.
I’ll look at that patch and make a cmake option at build time to turn on patch exposure probably tomorrow and merge it at head.
I needed these 2 changes to get all the presets generated:
sed -i "s/#undef SURGE_JUCE_PRESETS/#define SURGE_JUCE_PRESETS 1/g" src/surge-xt/SurgeSynthProcessor.cpp
sed -i "s/firstThirdPartyCategory/firstUserCategory/g" src/surge-xt/SurgeSynthProcessor.cpp
With this changes, factory and thirdparty presets are generated inside the manifest.ttl file, what is suboptimal, but not a problem for us. I just finished a script that splits the presets from the manifest to a separated file, and BTW, get the presets organized in LV2 banks:
What is a very good starting point playing with zynthian and Surge XT
BTW, i’ve been testing the SurgeXT with a RPi5 zynthian and i must say … woaoooo!! It’s clear to me that surge is going to one of the preferred engines in zynthian
Yeah great over on GitHub I just did a slightly-more-mergable and slightly-more-surgical version of the fix you have. Just waiting for CI to run but once it does and I merge you will be able to add -DSURGE_EXPOSE_PRESETS=TRUE to your first cmake build stage and then it will create the same manifest from your two seds (without one of the lingering bugs that your sed provides away from build time but which you wouldn’t have caught).
Super duper.
And yeah on a RPI5 or OrangePI5 or other it really works well. Like I mentioned on GH, some of the newer features (especially some of the non-linear filters and the modern and twist oscillator) can burn some CPU but the core features are built for a 2005 era PC, which is slower than a PI5.
Is it easy to get my hands on a zynthian with a pi5 in it? Like can I click buy somewhere and one shows up at my house? Or is it a ‘solder stuff together in a box’ thing? (which is also cool! But more likely to result in a ‘have a box of things to be soldered together one day on my shelf’ rather than ‘i actually use this thing’ )
Oh and after my merge you should make sure your script still works, but if it does, and you want to put it in the repo in scripts/misc/ and add a little doc/zynthian or some such we are always happy to merge such things. Open contribution project, and having ‘extra’ patches and stuff around which aren’t upstreamed turns out to be more work than just upstreaming them
There isn’t such a thing yet. @jofemodo is fixing some issues with RPi5 integration and making the hardware adjustments but it’s not yet finished, hence not available to buy. Zynthian is a DIY kit but there is no soldering involved. All parts are plug / screw together. It takes about an hour to construct (there are some informative guides and videos) and there are seldom issues. It’s fairly easy if you have reasonably good agility.
We could / should only use main output. The routing shown is wrong (which @jofemodo said he would investigate). It should either take first pair only or route each signals to left / right alternately. (I think the latter is by design and what is happening is a flaw.) We will see what we can do to correct this but it may be advantageous to compile with just stereo output which asks the question, is there a significant disadvantage to compiling with a single scene? (I haven’t looked at the design enough to know.)
@jofemodo we have a similar audio routing issue in Pianoteq. I thought we (I) had corrected that but I just tested and see not. Maybe it was fixed and has subsequently been broken by a regression or maybe I am just mis-remembering with a wishful mind . Maybe we need a rule plus an exception list so that we can set how output routing works per engine. (We have something similar for audio inputs and sidechain handling.)
I just fixed the audio routing issues, so now only the 2 first audio outputs are routed (stereo).
BTW, @baconpaul, is it possible or adventageous to limit surge audio outpus to 2 (stereo)?
Also, the new surge XT binaries and presets will be installed when updated Oram, so … update your zynthian please!!
We still don’t have access to the controls because we need to implement support for LV2 properties. This will be done in the next days/weeks. But hey … you have more than 3000 presets to play with it!!
Many hosts offer you a choice to wire 2 or 6 outputs, and surge is relatively resilient under both. Basically surge is a two-scene synth and the sum of the synth + effects chain goes out of 1/2, but the pre-FX a and b go out of 3/4 and 5/6 respectively. For zynthian you can safely ignore them and not connect them, assuming the juce LV2 code does what I’d expect.
If it really causes a problem, a compile time ifdef should work or the old code I pointed to on the GitHub issue i closed.
And yeah JUCE 7 LV2 params are different than some other things or something, which is why only some hosts work. I’m glad you understand this though, since I certainly don’t!
We should be freezing 1.3.2 fairly soon (next week or so) and I’d suggest, once we get there, you lock zynthian to a release tag.
Surge also has an input and can take side chain inputs allowing you to mix any audio in with the entire synth effect filter and oscillator chain in a variety of ways. This may be of interest to your community.
And as well as surge, there’s a surge effects bank which just makes each of our effects. Should build as an LV2 also and may be of use? You could at least get an implementation of clouds running at zero cost other than including the plugin.
I have currently implemented the side-chain inputs as dual mono, i.e. you can route to either or both individually. I can’t figure out if it makes any difference routing to one or both. I was able to hear the vocoder working on Zynthian but didn’t have a good configuration to hear it in its best quality - just enough to prove it is working.
Many (most) presets are too heavy for RPi4, causing severe xruns. I wonder if there is a way to identify which ones are more resource heavy so that we could thin them out for less powerful machines.
I also see lots of errors in the logs when presets are selected, e.g.
)
. Maybe we need a rule plus an exception list so that we can set how output routing works per engine. (We have something similar for audio inputs and sidechain handling.)
