@Codeman I’ve used dexed in Ableton and also to try out patches on my volcafm so I was really excited when seeing you ported it to the MOD Duo! Works great so far. It’s pretty lean as far as cpu so far for me. I wish algorithms could be interpolated smoothly without gaps but I’m guessing there is a technical reason for this.
Really impressed how smoothly Dexed runs on the MOD Duo. Thank you for your work!
Sorry, completely forgot about this…
Updated now.
many thanks for your reply!
Does the original do work with smoothly algorithm changes? I think not and will check this on Thursday (when I can play my good old and heavy DX7-hardware). I think this is not easy to implementd - perhaps not really working. What may work: Changing the algorithm for note-on events. But this needs some tuning in the code, because the current code looks for all carrier-OPs and if they are all have zero output level they are discarded from calculation-loop. This saves much CPU for non-used notes.
Regards, Holger
P.S.: Do you know how to install SYSEX-files? Should I write a small manual?
Many thanks! This last version works nicely and stable for me. We will try it at stage next month.
Regards, Holger
The original also does not do smooth changes. The volcafm does and I have a lot of fun sending cc to constantly cycle through huge parameter changes during the same sequence. Glitchy fun for days! 
I assumed this wasn’t possible due to some kind of limitation but thought it wouldn’t hurt to ask.
I’ve tried out different sysex files just to do it (following tuts like this: https://www.youtube.com/watch?v=wnVlnSwz0_0 ) but I have more fun just tweaking a patch then trying to fine tune one and save it.
As for a manual, everything seemed pretty clear when I opened the plug and there is already a host of great info on the dexed and github site. Someone else might like one but I think I can find what I need to find elsewhere.
Next on my agenda is to figure out a good solution for midi mapping as many parameters as possible. Maybe I’ll try my quneo (cc on each axis of each pad has been fun in the past.) What do you use to perform and edit Dexed on the MOD Duo?
Really nice idea - will keep this in mind. Perhaps I have sometimes enough time for trying this
I made a simple script in the directory bin which converts a DX7 SYSEX to a usable user-preset file.
We (I personally play guitar in the band - but the DX7 and the MOD are mine 
) are currently using no special controllers (only mod-wheel). For our next gig we want to try the MOD using Dexed, FluidSynth and setBfree. Currently we have no idea if we want to map anything special.
I also own a Roland A880PRO with some controllers - this would be the full replacement for the original DX7.
Regards, Holger
Hi @falkTX,
there is a new version of Dexed: 6a2a90c869f27c6e844a534da73ce220345fda98
A bug (which seemed to occur only with Ardour5) is fixed. Also Dexed is running stable on the Mod-Duo for me (and I hope for others, too!). So, perhaps there is a chance to move it into stable?
Regards, Holger
well, there’s a lot of things wrong with the code to be honest.
you’re checking for NULL after ‘new’ operator, which never happens unless you build with -fno-exceptions.
on c++ a memory allocation error using ‘new’ will throw instead of returning NULL.
then, you’re calling exit() from within the plugin when something bad happens.
since the host is running in the same process (and jackd too), you’re basically quitting all the audio if your plugin fails to load.
I remember you commenting out some cleanup code, because deleting some c++ objects was triggering a crash on plugin removal. Without those, the plugin will leak memory every time it’s loaded.
From the git logs the behaviour seems to still be there, or am I missing something?
EDIT: dexed updated now
Thanks for analyzing and reporting. I will try to fix this soon. This is “my” first plugin (not really my, because I was just trying to make a native LV2 port with code from others) and I am a networker in real-life, not a programer. So I make much mistakes and may write unclean code - please excuse.
The big question is:
I know you are all have to work hard at MOD for the Duo as a product. If Dexed should be getting stable (what is currently my personal wish): Are you (or someone else) is willing to tell me what I have to do for this? If not, I will understand this. The problem is that I don’t have as much experience as some of the pro-plugin-programmers.
Nevertheless I will try to fix your mentioned problems asap.
Thanks && Regards, Holger
EDIT: commenting out cleaning code was fixed in bf24d15002f79d8e9de1d85da2aeacd9c7be8c99
It’s fine when you have the plugin in unstable, you can do all you want there.
But if you want to get the plugin into stable, we need to have some assurances that it will work correctly.
It’s great that you have got a working plugin already, but the last steps now are the boring and painful ones…
Because it’s your first plugin, it’s understandable that you missed a few obvious things.
I don’t want to be rude, but it’s perhaps better if you learn more about programming first.
You mention you fixed the leaks before, but for example the engineMkI, engineOpl and engineMsfa objects that you allocate on the class constructor are never deleted.
I also see several class static functions being called on the constructor, which tells me the plugin has global state. I mean this:
Exp2::init();
Tanh::init();
Sin::init();
Freqlut::init(rate);
Lfo::init(rate);
PitchEnv::init(rate);
Env::init_sr(rate);
I did not check what those do, but calling such methods on each plugin instance load is certainly wrong.
If they change some global state, then you might get weird sounds (or crash) if you load a new dexed instance while one is playing notes at the same time.
Globals are a big no when it comes to plugins, as we have them running concurrently on different threads.
It’s really out of the scope of MOD to coach each developer how to do plugins, specially how to do them properly. Audio plugins are not specific to MOD, so there are a lot of existing resources out there to learn from.
The conditions that apply to LV2 plugins for MOD are the same for all other plugins, for example:
Here comes the usual link http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing
Of course not all plugins do this, even commercial ones.
But then the user is the one that has to deal with it…
Other things like proper cleanup, checking for errors and handling them in a reasonable matter - those are common to all software, not just audio plugins. If you want your plugin to be seen in a commercial product, then you really need to pay attention to these details.
Wouldn’t that be a useful item for the MOD wiki then? A few links to other sources about general audio plugin development, the how-to-install my own plugins, the gen-introduction video and the 3 +x conditions/requirements you just mentioned make a neat little compendium.
I second this motion
Most of that information is already written here:
http://wiki.moddevices.com/wiki/Developers
I added links to the Max gen~ page and other resources now.
Cross-building and deploying plugins is explained there.
This page is nicely populated! What do you think about a paragraph about the process to get a plugin into the stable repository and the requirements (locking, global parameters… ? Probably developers will want to publish their plugins and have them run on other musicians’ Duos.
We’re putting a procedure in place for that.
We’ll publish it soon
@Codeman - I’d like an fm synth on mod. Could you put the code on github and I can maybe contribute some?
looks like it. Thanks I didn’t know codeman’s GH handle and search didn’t turn up much.
(Why you guys use all kinds of different handles is beyond me 
)
Hmmm… “Codeman” in every flavour was not available at creation time of my account. And D-CORE or D-DUMP was my callsign at Flightgear
You should checkout the “native-lv2” branch…
Thanks && regards, Holger
occam’s razor wins again.
looking now. cheers!