Will the Befaco Oneiroi be coming to the 4ms Meta?

Plugin Development
1
2 Likes
2

Post from henner, Nov 7

“Context is experimenting with compiling Befaco Oneiroi which will have to remain closed source, and which I’ll have to distribute as a .mmplugin eventually, so it gets a bit awkward debugging as built-in, copying out, building in SDK etc.”

3 Likes
3

Woow, let’s hope this one will come to the MM….

1 Like
4

:eyes:

PXL_20241217_215111230
PXL_20241217_2151112301920×2557 361 KB

(still loads to debug, optimise, fix etc but it’s making the right kind of noises, so hopefully on the right track. It’s been a busy 2024 and I need a wee break though so definitely nothing released until the new year)

10 Likes
5

You rule, @hemmer.

Just curious: Will the Meta Module version be paid (as the VCV version is)? I think it might be good for the Meta ecosystem for there to be a high-profile paid module.

1 Like
6

This is cool! I had one on pre-order but after hearing all the issues people had with the first batches I pulled my order and got something else instead.

7

Mm good question - I’m honestly not sure, will discuss with others involved and get back.

1 Like
8

This is so nice :star_struck::star_struck: woow.

9

Good work man!

Looking forwards to seeing this one.

10

Hi Hemmer nice site and projects you are doing,
do you know if the Bastl Pizza is coming to the Meta module?

2 Likes
11

I asked and it’s not a short term priority for them I think but let’s see. (It’s a bit of a trade off, do we spend time releasing new modules for VCV which benefits a larger group or existing modules for MM, which undeniably benefits a much smaller group. Hopefully both in the end, and MM porting process is getting easier!)

1 Like
12

Probably not technically feasible, but it would be great if a mechanism could be implemented that would pass a token from VCV to the MM via the .yml file (or some other mechanism) that would verify the purchase and ownership of premium plug-ins. I realize that such an approach would not be satisfactory for those who build their patches exclusively on the MM, but you can’t accommodate everyone’s workflows. I’d gladly pay the $35 asking price for the Oneiroi plug-in to use it in my MM.

13

DannGreen’s a super smart guy. I’m fully confident he can code some kind of cryptographic unique identifier for our Meta’s. Maybe even before breakfast.

1 Like
14

hard to have a ‘protection system’ in place as the firmware for MM is open source (and so is the hub) , and so public. meaning someone could easily ‘circumvent’ the system.

note: the project being open source was an important part of my purchasing decision, so any move away from that, Id be pretty unhappy about. (not that I think 4ms would do this)

given this ‘undeniably benefits a much smaller group’, I think the route chosen by Sapphire is a good one to follow.

the module is premium on desktop, and so you get a benefit to purchasing that even if you use on the MM (and many of us create patches on vcv, so would want this)
but the few that just use on the MM , get it for free.

thats the simple way…and frankly, probably not going to loose much revenue for Befaco.
(personally, id buy in vcv just to support the project… as I think would others)

other than that, sell the mmplugin via your own shop… doesn’t really need protection.
Im sure the vast majority of MM owners are trustworthy, and want to support developers.

3 Likes
15

Sadly the MM port needs to remain closed source (VCV premium terms). But we don’t want to double charge and a closed source but free as in cost MM plugin is the most probable model at this point, as you describe.

4 Likes
16

Todo:

Basic compilation
Producing sound from all major sources and FX
Work out how to deal with alternative knobs*
Debug buttons not working
Improve legibility of graphics
(nice to have) Menu seperators**
(nice to have) Work out saving buffer between power cycles

* Oneiroi (and a few other VCV modules too) heavily uses a pattern where alternative parameters have a different knob (often different coloured) and the visibility is dynamically edited according to module state. This doesn’t happen in MM because Widget::step isn’t called and GUI is drawn elsewhere (previous discussion), so we have the knobs all drawn over each other. A workaround for now might be if the currently selected knob (either in the roller menu or due to user interaction, i.e. mapped knob movement) is drawn on top (last?). I tried to modify ModuleDrawer to draw this active parameter last but it’s a bit hairy, so pointers here welcome @danngreen ! Alternatively if there is a use case, support for parameters having a visible state as to whether they are drawn or not might be good (and we can put custom code in process to work out and set appropriate visibilities)? Branch oneiroi on metamodule repo should build (but references a private repo, which Dann you should have access to).

** Oneiroi has 68 parameters, so the menu gets a bit much. It’d be cool to add seperators (in this case “Alternative Parameters”, “CV Amounts”, “Modulation Amounts”).

3 Likes
17

v2.0 does call Widget::step and Widget:draw, but only for widgets that are on-screen (currently just in ModuleView page) and aren’t known components (like knobs). We could try calling step() for all components that are on-screen.

A workaround for now might be if the currently selected knob (either in the roller menu or due to user interaction, i.e. mapped knob movement) is drawn on top (last?). I tried to modify ModuleDrawer to draw this active parameter last but it’s a bit hairy, so pointers here welcome @danngreen !

You can tell LVGL to draw an object on top of its siblings with lv_obj_move_foreground(). I tried it just now, putting that line in the redraw_element(const Knob, ...) function whenever the knob is actually redrawn. That makes the most recently moved knob drawn on top. Something similar that could be done to bring it to front when scrolling the roller, though it would probably need some logic to find the knob LVGL object first.

Yeah, I think this is the way to go. We could add bool visible to BaseElement. It would need to go into v2.0 since it breaks the ABI.

That’s a nice idea. How would the roller know where to add the separators? Maybe detect the pattern “Header: KnobName”? Or we could come up with a convention like “:Header: KnobName”

Or, if we add hidden parameters, maybe the hidden ones drop out of the roller. So the 68 params would be cut way down.

18

Thinking a little more on this, adding a bool visible to the BaseElement type would actually not work since the Elements list is const. I’ll brainstorm some ideas. Perhaps the new dynamic element drawer in v2 (which calls Widget::step anyways) could help…