Prototype to adapt BEAP UI to M4L

[baptistemanson]

I made a small JS working prototype to solve my problem of adapting the UI of BEAP module to M4L. You can see the video here: http://www.youtube.com/watch?v=zrlWNczkXLo

By removing the documentation of inlets and outlets, the BEAP modules fit nicely into M4L height limits and can placed easily in Presentation mode. Do you like it? I saw Peter talking with Matthew about it in a former UI discussion on Github.

It requires to add a thispatcher in the clippings, but does not require adding an inlet (I'm using a receive object for this).

[stretta]

Hey, that is a good idea.

[petermcculloch]

One other thought might be that it could be done via adjusting the bpatcher's offset and size. (i.e. shrink the size of the bpatcher by n•2 pixels and offset)

I think your approach is probably a cleaner one though it requires some modifications to existing patches.

If we're going to do that (and it sounds like a good idea to me though I'm on lockdown at the moment with dissertation so can't do anything for a few more months) maybe that should be included inside an object, maybe something like BEAP.module? That way any additional configuration could be added later. If we use uniform scripting names for the panel, (I'm guessing this is mostly the case) you could script changing the background colors, for instance. This could also maybe fill the role of loadbang with the js sending out a bang on instantiation.

PM

On Feb 20, 2014, at 7:13 AM, Matthew Davidson notifications@github.com wrote:

Hey, that is a good idea.

— Reply to this email directly or view it on GitHub.

[baptistemanson]

Thanks guys for your feedback!

About the approach, I was not able to change the offset nor the presentation_rect of the bpatcher without having a thispatcher inside the bpatcher. I used send/receive to avoid adding an inlet. I could also have allowed messages on the first inlet of the patch, but I didn't think about that when I made it.

The current implementation has those limitations:

• works in presentation mode only (but the code could be ported if I know how to detect presentation mode),
• requires the patch to be unlocked when trying to hide the inlets/outlets (the presentation_rect cannot be changed otherwise),

For my usage, it would make sense to automatically activate it when switching to presentation mode.

I will try to factorize the bpatcher elements in an object as Peter suggested, so we can add new features to all the patches at once. As a proof of concept, I will try to add after a native skin feature, which will use the colors of the Ableton Live skin for the background panel colors.

Thank you again.

[baptistemanson]

I'm not able to read presentation_rect and patching_rect separately. I only was able to read rect parameter from the bpatcher.

bpatcher.getattr("presentation_rect") // null
bpatcher.presentation_rect // null
bpatcher.getattr("rect") //either patching or presentation rect - not sufficient enough except if i can detect we are actually in presentation mode...
bpatcher.size // null

I posted the question on the forums, but I'm pretty stuck with at this stage.

[baptistemanson]

I used a workaround, that seems actually cleaner. The only impact is to rename the black panel with the inlets and outlets to "backpanel". The new UI Control module then introspects every bpatcher and does its shrinking/expansion procedure.

So far, I ported Oscillators, Effects, Envelopes to the new system (see my fork). I took care of putting in background those panels and lock them, resizing them to the same height. In M4L without the inlets/outlets, we can fit exactly two modules in height modules are 114px high expanded, and 97px extended, M4L is 200px high). We are lucky!

Best,