Well lets face it, the overlays available from other sources so far arent much beyond proof of concept demos, still tended to be made in max, and dont involve polished UIs. The Expressive E stuff will probably be the first to get beyond that, although now we know that we’ll be waiting a fair while till we get out hands on even the first of them (late Q1 2026 or early Q2 2026 was mentioned as the new target in that Sonicstate video).
Multiple individual apps wouldnt actually bother me at all, but I suppose Im not surprised to see that Expressive E look to be going for a different, more cohesive approach.
The fact they had to switch Osmoses to demo the prototype version for sonicstate in the video perhaps implies that more firmware changes are coming to enable this stuff to work the way they want it. Whether that involves some tweaks to the overlay feature or some other changes to the engine I am obviously not able to guess. Or I suppose it might involve some changes to expressive E’s own layer of firmware as opposed to the Haken side.
I should probably have said that the overlay thing for Loris probably represents the most polished overlay we have access to so far, but its still very obviously max and the choice of background image etc doesnt involve the sort of UI polish that Expressive E are keen on.
Speaking of Loris, theres still an awkward gap where the stuff that Loris enables isnt really joined up with the world of Osmose that Expressive E promotes. As a result, maybe a lot of Osmose users dont even know that those new possibilities are even available to them.
Some strange things happening with pricing in the UK. I managed to purchase at £1729 from G4M. Andertons, Juno, KMR had similar prices but a few hours later G4M, Andertons and Juno had raised the price by £200. Be interesting to see if KMR raises when it opens.
It’s still going to be a long time before I can upgrade, but I think I’m of the mindset now that a pair of 49’s would better suit my needs than a single 61.
I have space set aside for the 49 that I’m using, and the stand that it’s on has a second tier. Trading up to 61 would mean moving furniture.
Not that I need 8 octaves, mind you. But an EaganMatrix patch for either hand would be nice, and that’s a challenge on one unit, even with VST synths. (Pressure Glide can interfere with a traditional keyboard split)
Plus, leaving one sound in memory while a second sound loads might offset the load times enough to be viable!
(That last bit is sort of facetious – I think the new overlays are EE’s solution to load times. Stick with one EM patch, and presets within that should load instantly. Under this model, two units mean two overlays in play. That seems very workable.)
The new overlays are EE’s answer to requests they’ve had since day one to make the editor better, to make sound design more accessible. They havent been done because of the preset loading time issue that only started more recently.
having read quite a few posts on the Osmose Facebook group.
I do worry that some are expecting a little too much of overlays…
I get the desire for a more accessible editor, but calling overlays this is bit of a stretch… they really are a skin, over a (complex) patch with many more parameters.
as for load times… it doesn’t really change anything.
currently, afaik, there is no mechanism to save an’overlay preset’ on the eagan matrix. you have to save as a ‘normal’ patch, and that patch is presumably going to be quite large given the complexity of it.
currently, the only concept of ‘overlay preset’ is within the particular overlay editor on your computer.
I dont even think the EM ‘marks’ patches as originating / tied to a overlay (template)
ofc, its possible this will change in a future firmware (haken and/or osmose).
… and for sure, 10.52 was the first iteration, they will learn from it in usage.
Osmose separate storage could help this, they could move this persistence from computer to hardware.
don’t get me wrong, I think this was a clever move by haken…
they have to retain compatibility with the existing presets and editor, its mature, its proven … it is the heart of what makes the eagan matrix.
so a skin with more parameters is a really good solution.
But, Im intrigued to see how many will be happy with this ‘tethered approach’.
I suspect for many, it’ll initially be a solution, but soon there will be cries for more possibilities for change on the Osmose itself.
Something along the lines of Reaktor/SynthMaker/MSoundFactory/Kontakt/Max would be nice, where a UI can be defined as part of a schematic and then presets can be made, saved and shared for this schematic.
I think Kontakt is the best analogy …
multiple skins on an engine, and presets that are particular to that ‘skin’
I was a surprised that 10.52 didn’t have some way to tie ‘derivatives’ to the main patch.
but I think the idea is more, having this overlay editor open when your using that overlay - and perhaps just saving, if you have a particular favourite?
looking at EEs product range, I think they don’t mind this tethering, they are marketing VSTs quite strongly alongside the Osmose.
anyways, yeah, I could see it not being a big move for EE to have presets for their overlays stores on the Osmose, in nvram… they have already made a bit of a departure from Haken on presets storage.
its also a bit easier to do in a ‘specific use-case’ scenario e.g. official EE overlays, and given the effort they look to be spending on their virtual analog overlay. its seems worthwhile.
Yepp, saving presets for these overlays would be key! As I understand it most of the Meldaproductions products are actually schematics for MSoundFactory (or every other component that they need for anything else gets first implemented as an MSoundFactory module ). And people are happily using these standalone schematics, using and creating presets for those without having to fiddle with the complexity of the full modular system. (Presets for these schematics can also be submitted and then downloaded by all other users). MSoundFactory, Kontakt and EaganMatrix are more on the “still a (super capable) synth” side. Max, Reactor and SynthMaker could be argued as being dev environments already…
Hm. Osmose already has an onboard LED screen, six knobs, two sliders and four buttons on board. What if that could be utilized by an “overlay” that would not need any external computer…
Loading a patch takes time. Once loaded, you can dump a bank of CCs to dramatically reconfigure your synth, and that happens instantaneously.
It’s true that user presets currently reload the underlying patch, even when the patch is common between presets. Perhaps that will change with another firmware update. In the meantime? Don’t use those; they’re stupid.
It’s also true that most of our patches didn’t prioritize supporting a broad enough range of sounds through their macro controls, so you have to be pretty selective about which ones you load if you don’t want to load a lot of patches.
only if either:
a) you use a computer to change overlay presets
b) the osmose firmware is extended to cover
i) save/load of presets
ii) support for more than the 8 macros on the display
and that was my point,
overlays as they are currently, and even shown by EE in the sonic state video don’t really solve the issue outside of when you have a computer attached.
to be useful to most users, and to reach the expectations I think many have they will need more firmware support ( * ) .
as above, I don’t see any reason why this would not be possible, either by Haken or (more likely) EE, but its not something thats even been hinted at (yet!).
this is why previously, I said, Id hoped that they’d announce/demo some kind of overlay support within the Osmose firmware (on release of 61 key), as I think its an integral part of the solution thats required going forward.
(and frankly, whilst I love what EE have done, they’ve been a bit slow on the firmware dev front)
( * ) ok, strictly speaking you could ‘implement’ hardware support yourself using something like the electra one. but I think most users would not take kindly to that suggestion as a solution
Even a large patch on the EaganMatrix is not much memory space. RK’s Dual Subtractive could be one of the most extensive overlays made and it’s still less than 2k on disk.
In developing the scanning process in CHEM, I extensively measured patch load times in order to make enumeration of presets on Osmose as fast as possible while remaining error-free and while there is a correlation with size, there was not a lot of variation on load times. I’m not clear on whether it’s a hardware limitation (slow storage, limited bus, or limitation to MIDI interface) or something else. Loading from internal in the DSP is pretty fast, so RK outlined the obvious for them to use the EM memory as a cache. The trick there is cache management, and when do you do the slow transfer, which can’t happen at the same time a preset is being played.
EE had trouble finding qualified embedded software developers. They also had requirements that narrowed the scope (had to proficient in French, had to work locally). They had an open job listed for 2 years. Apparently they’ve found someone to rewrite the firmware at last, because the job listing isn’t there anymore.
probably not a good idea to use caching techniques like LRU etc, as then preset loading time becomes less deterministic for the average users., EE want to kiss.
but, they could quite easily make decisions like store playlists / favourites in the EM memory, offload ‘others’ to their own nvram
easy to understand / implement etc, but EE are trying to reduce complexity, so adding extra layer was probably not very desirable. again kiss.
also this only really address performance concerns,
rather than more casual players, who may well just browse presets (e.g. for inspiration), where the time to switch is even more noticeable / problematic.
it maybe they hope to optimise it later, so for it to become less of an obvious issue.
going back to Overlays, these would be a good case for storing in EM memory,
then storing the ‘overlay preset’ in thier own nvram…
gives performance for loading the overlay, but then the ability to quick/easily edit the overlay ‘parameters’ from their own nvram.