Current status?

Eagan Matrix Eagan Matrix Dev
1

I’ve been playing with the api a bit (on EMM),
and wanted to discuss the current status of 10.35 with respect to editor/api.

partly, just to confirm my understanding is correct

I was playing with the Ratio and Jenny ovelays, I noticed a couple of things.

a) change in the overlay patch do NOT update in the EM Editor.

Im pretty sure of this, but want to confirm…
e.g.
I could not see changes to the extended macros.
I also could not see other changes being reflected.

my assumption is, that the EM Editor has not been updated to use the ‘api’ (poke etc).
and so its only updating to the original (cc, non-stream based) messages

Ive not verified this, but thought Id ask before digging into the code to check !

is this the case?
if, so, is it planned to change this for release… or this is a nice to have for the future?

(I don’t mind, I can see why its not necessary, really just want to confirm whats going on ;))

b) overlay synths do not select patches.

as far as I could tell, if the user want to use the Ratio overlay, they have to load, and manually select the ratio preset.
I assume this will not be the case for release.

for my synths, my plan is to actually send the ‘required preset’ when the overlay starts…
(I’ll kind of ‘embed’ it within my ‘app’) so the user does not have to do anything.

c) does the firmware send back the ‘poke’ message on preset recall (related to (a))

use-case : user saves my overlay onto the EMM, if they then recall this preset whilst my overlay editor is running, I want to get back the same messages as I used to configure…
i.e. its a full bi-directional protocol.

k, disclosure, Ive not checked this yet… again just asking as I assume its easy for someone to answer :wink:
and as a dev, I need to know… should I continue work on my current api, that decodes the 10.09 messages, and translate these to the new 10.35.

again, for clarity… Im not asking for any changes, or have expectations :laughing:
I just need to know, to frame some of the development work im doing.

2 Likes
2

a) Is a known bug (at least RK knows it’s a bug ;-). It’s not sending any updates back to the application (whether HE or custom app) at all, in either the old or the new MIDI protocol, and not specific to overlays or extended macros.

b) yeah, it would be easy for them to do that. For a custom one not a system preset, an overlay synth can send the preset to the EM when it loads. This is good for a commercial product that wants to keep the preset definition proprietary.

c) no idea - you’re ahead of me. I have 10.34 and no overlays/overlay presets. Looks like I need to ask Lippold for an update. It sure would be nice to have access to the updates when they happen. The preset .mids in the HE folder for 10.34 appear to all be the old MIDI protocol.
To answer your question, it should be straightforward to test, once you get further in your implementation.

1 Like
3

ok, so done a bit more digging in a & b, which as I mentioned are related.

current status (as in functionality/implemented) on fw/editor.

Editor is sending the new protocol when you make change,

however, it still supports the old protocol,
so you can drag n’ drop and old preset file - and it will load, render and send AS IS (old protocol) to the EMM.

if you switch presets on the EMM, then the FW will send the preset in the NEW protocol which the editor understands/renders

I think the summary is…

the editor is working with the new protocol.
(editor just sends presets as-is, so no change there… it never interpreted)

the firmware supports both, so that old midi files work. but it will send the ‘model’ to editor in the new protocol (so fw does the ‘conversion’)

and back to original points of a and c.

(a) ok, this is really ‘no change’ from previous behaviour. so not a ‘bug’
the assumption has been that the editor keeps its own ‘cache’ of the state, so the FW does not report back changes made.

this is only now problematic as you have two ‘editors’ in use, so one is not going to stay up to date.

(c) yes, this should work. we can see the FW is sending back new protocol on preset change. so as long as your ‘application’ responds to these then you OK.

(I’m not sure if current overlay synths are doing so - I’ve not retested since having an idea of what should happen ;))

3 Likes
4

Not reflecting the controls in the midi output is still a problem. Any time there are more than one source of controls going to the EM device.

Without this reflection of changes, the UI of any program working with the EM will get out of sync. The scenario is when using the software alongside a MIDI controller (knobs and sliders). In 10,.09, control changes made by the Midi controller are reflected in the app UI, whether the app is the Haken editor or my software. In 10.34, with exactly the same configuration, the EM does not reflect external parameter changes. So the UI is out of sync with the state of the device. Happens in both the 10.34 HE and my software and I’d expect the Overlay synth to have the same issue.

Interestingly, I thought the same applies to changes made in the device menu, but I just checked, and the EM does transmit changes made with the on-board menus, so ok there. It’s just the scenario when there are additional sources of control information.

1 Like
5

yes, this is what I said…

I’ve not tested with a midi controller, rather I was looking at overlay synth and the HE.

generally it looked like , 10.35 was acting similarly to 10.09.
but the issue is that works in 10.09 because there was usually only ONE client, the HE, so it didn’t need this ‘sync’.

I did see some of the CC messages still being re-broadcast, but I didn’t look to see if it was all of them, so not sure if thats a 10.34 vs 10.35 difference, or just we are looking at different use-cases.

as I said in OP, my main focus (for (a)) is about how HE and Overlay will work together, and what that means - and if its a bug (so will be fixed)

the ‘current status’ is…
you won’t want to run HE and overlay side by side, (not multiple instances of an overlay) as they will be out of sync.
but this is possibly not a ‘bug’, as its similar to 10.09, however, its definitely a desirable FR :wink:

ofc, to ‘fix’ this the editor etc, will have to take care that if the firmware re-broadcasts, then it doesn’t start sending it back again.
and I know from experience, that can get a bit quirky if you are not careful.
so it may not be a simple ‘fix’. but thats up to Haken Devs to resolve :wink:

1 Like
6

The way the reflection can work properly, and the way it worked in 10.09 FW, is to only send on change. If there is no change when a cc is received, then it is not sent. In other words, it’s a change notification, not mirroring. In that situation, any change gets propagated throughout the system and settles (the loops are terminated).

The alternative if this isn’t fixed, is the app must handle the routing of the controller’s MIDI and process it’s MIDI stream. This is a stiff requirement because you have to build the UI for selecting the partner MIDI sources and wire them up (something my software currently does not need to do).

1 Like