MEC and Orac integration possibilities

thetechnobear · June 20, 2018, 11:51am

This discussion originally appeared in the Pure Data patch with parameters in the Pisound App tutorial. @mzero moved it here as the discussion moved on to something quite beyond the tutorial.

I think when you are discussing things that are provided by MEC (kontrolrack ec) , that these should reference back to the original project.

it concerns me, that this tutorial makes no reference to this, and makes it sound very specific to PiSound…

(note: for sure it should be clear the PiSound app is very much blokas work, MEC is the PD side)

in particular:

MEC (and so all this parameter stuff) is not at all specific to PiSound, it is cross-platform running on any rPI, Bela , Organelle , and even macOS.
I built it so that patches could be written for one platform and then used on another, without patch developers getting involved. (e.g. write on an organelle and then bring it over to pisound) , i.e. to get away from ‘closed walls’
I built Orac on the same infrastructure, and in many ways is ‘mec-kontrol’ v1.5, since its much more flexible as it provides a modular structure where UIs do not need to be statically coded.

this last part concerns me, the way this tutorial is written, some are going to get a bit confused when I release Orac in a few weeks, and its using a rather similar method to write modules…

(we have already had one user here on the forum, that didn’t realise there was a connection with the parameter systems)

Is the PiSound app going to be open sourced? so that other platforms that are using MEC could use it.

I respect you want it to be an ‘easy to read’ tutorial, but I still believe this can be done, whilst introducing some of the goals of MEC.

Pranciskus · June 20, 2018, 3:04pm

Thanks for pointing this out. Getting feedback is the main reason of why we decided to move part of our documentation here to the forum. The App section of our official documentation had the credit and the link to the MEC project. It is now mentioned on the Pure Data parameters and MIDI section too.

The Pisound App at least in the near future won’t be released as an open-source project. The app’s design itself allows to expand/edit its functionality without the need to change the core code-base. Also, it’s something that differentiates Pisound from other similar projects and we just want to hold on to it for a bit longer.

Coming back to the issue, the goal of this tutorial is to show the fastest/easiest way to create a Pure Data patch for the app without going into much explanations on how everything is implemented behind the curtains. And as the MEC package is installed during the Pisound’s drivers setup/update process, and as there aren’t some beginner-friendly resources on your GitHub, that could be linked for additional reading, it was overlooked.

I have mentioned before, the MEC is an amazing initiative of yours that is going to be used by many projects in the future, and we should definitely have a proper presentation for it. The question now is should we have a dedicated page here on the forum, on our documentation page, or e.g. you are planning to create a separate user-focused page on GitHub that we could link and contribute to? Also, what would be your suggestion for dealing with different per-project MEC uses from the documentation/presentation standpoint? Different projects can utilize MEC package differently, like ORAC uses multi-module model, while Pisound App at the moment uses a single-module model, aiming for simplest integration possible.

If it looks that we are presenting your work as our own, that wasn’t our intention. I’ll update the tutorial to have a proper credit to the MEC package. And note, that these tutorials are wiki-based, so you can always make the changes on your own as you see fit.

thetechnobear · June 21, 2018, 9:09am

I think its great if PiSound can be a complete ‘off the shelf’ product that allows end users to utilise a rPI without Linux knowledge. a ‘hardware PD’ box.
In many ways, that’s my goal for the rPI too… (though not necessarily w/ PiSound)

I also understand/respect that you want to have this as a differentiation from other products.

I guess the question is…
Im bringing other open source projects to PiSound, e.g. MEC, but also Orac which contains 30+ modules written by C&G for the Organelle. Mutuable instruments ‘modules’ (clouds, braids, elements, rings etc) , and Ive also been demonstrating Norns on Push2/PiSound.

so I guess I have a bit of an uneasy feeling, if this is all one way …
e.g. if PiSound starts to have ‘exclusive’ patches and apps as a competitive advantage, whilst others are allowing stuff to come to PiSound.
it kind of feels unbalanced.

this is why id have preferred building on Orac, so that these could directly go back into the ‘pool’.

(of course, I could ‘port’ your patches, I believe they are gpl?, to orac, and release… but that feels odd, since you have already done the effort - would it not be better if they were released under your name)

this feels to me like open source, where everyone contributes, and the end users are the winners.

put another way…
I think PiSound is the best music solution for the rPI, in fact arguably the only complete solution (midi + audio in and out). this is because
a) the hardware is very simple, and high quality/efficient.
b) blokas support the software side, rather than chuck a hat at you, and say get on with it.
so for end-users I have recommended it many times.

(did you not notice, I put PiSound up-front in the norns demo… similarly, Orac 1.1, I hope to ‘promote’ on the PI using a PiSound)

really the only alternative is an external usb audio interface, but that’s bulky…
(an organelle/norns is much more expensive)

so I do not think you have to worry being unique in providing a rPI app or even patchers, you’d almost be better just promoting the rPI as a music platform (probably the bigger ‘question’ for most)… and they will naturally come to you for the hardware anyway

( a bit like Steinberg/VSTs… sure they sell a product, but vsts generally made the whole market more viable)

so this is my take, its not really about ‘credit’, its more about having a solution that can enable users to use across platforms (e.g. developing patches on your mac, then chuck it on to a rPI/PiSound) .

of course, I recognise, im not trying make money selling a product so perhaps I have the luxury of having this attitude to open source… so im more voicing this, to see how this might work for blokas.

as for how to present… its a good question, and probably one we will have to address in a few weeks when I release Orac 1.1 - at that point there will need to be a bit of clarity, as its going to raise a few issues.
e.g I suspect Orac is not going to work with your pisound app, and ive no way of testing given I don’t have an android device.
perhaps that doesn’t matter, but I think there might be some that might enjoy Orac given its popularity on the Organelle

also I still think the approach for the single module model is not the right way… as I mentioned before, there is nothing stopping you have a single module with fixed routing in Orac that still follows the same core architecture and yet retains compatibility…
(the router module is not a requirement, like every module it can be switched out, and doesn’t even need to be a module!)
the only thing you would require to do this, is a single option, to deactivate module selection, and even that I think is potentially unwise… e.g. you could still use it to allow you to swap in/out different fx for your ‘synth’.

( I recognise, potentially hardcoding the router/clock is something you might want, as I do understand that is a level of complexity for end-users, and some might prefer a non-modular interface)

the other advantage of this approach, is ive already created videos on how to create modules for orac, so that’s a resource, that patch developers could use.

finally, I guess my main aim here is, is to consolidate, so that we all push in the same direction, we all have limited time, and this is a pretty niche area - so we are unlikely in the short term to have a mass of open source developers rushing to help … so definitely a balancing act of how we both reach our goals.

Pranciskus · June 21, 2018, 1:27pm

We are stepping into a much broader discussion here. I can’t comment much on the specific implementation details. Maybe @giedrius will add something later.

First of all, for the rest of the discussion you should think about our app as the Pisound’s User Interface, it’s not some kind of different project on its own, it serves the same purpose as e.g. screen and wooden buttons on the Organelle - provides a way for the user to interact with the system & the sound engine. You have the board, you get the UI. Making it an open-source project and allowing other platforms to use it would introduce an additional layer of responsibility for us. We just don’t have the resources to cover that.

It’s strange that you suggest that we should have based our entire Pure Data integration efforts around the project that isn’t even released yet for Raspberry Pi and in essence, currently is targeting a different platform & user interface.

Despite that, we have discussed possible options on how we could integrate your Orac project (at its current state) within the app - it’s on our roadmap already.

It would seem that it should be a straightforward process, but once you start getting into details a lot of uncertainty starts to surface. How the router interface should look like or e.g., all of the Orac’s sequencer modules are built completely having the Organelle’s UI in mind - so, should we try to mimic the Organelle’s interface inside the app, or should we introduce some completely new approach, or maybe Orac should have different modules for different platforms (not the goal completely)?

Please note, not exclusivity is what we are after, but simplicity and the highest possible value-created and resources-spent ratio. What we have achieved already, thanks to your MEC package, is a clear single module approach where the end-user can and, most importantly, is enjoying Pure Data integration. It’s not our final approach, it’s work in progress and I think that we are moving in the right direction, at least compared to e.g. the Organelle’s default approach.

Your overall goal is great and I am a strong advocate of having a standardized, consolidated ecosystem, but do have in mind, that it will take time and effort, and some questions regarding Orac need to be solved working together.

thetechnobear · June 21, 2018, 5:43pm

what I suggested, is entirely possible with the same source code you released your app for.
also I was not suggesting you had to front-end Orac, rather that the patch could have been written to be compatible, to be a module… to ‘throw a module’ back into the pot, to help grow the ecosystem.

but, perhaps this is all premature…
once Orac is available, users will be able to choose if they write modules for orac or ‘standalone’, and im sure like on the Organelle, there will be a bit of both.

I just think its a shame that in the end both Blokas and I have had to write a front-end app, duplicating significant effort.
I had hoped that we could avoid this same mistake with patches

Giedrius · June 22, 2018, 3:05pm

The way the patches are made for use with Pisound should still be compatible with MEC in general - it’s just another ‘rack’ with a single ‘module’, without any ‘resources’ to load or swap. Any UI built for mec-app should be able to deal with such a patch.

At this stage, the latest release of the Pisound App is an increment with much needed functionality, huge thanks to your MEC project. Keeping the moving parts in our app limited, and control integration distilled to the simplest form we could get it to, we can ensure a high quality release.

As Pranciskus said, it’s not the final stop for the app, and integration with ORAC is on the roadmap, with all the module use cases. When that happens, the patches we release will get updated accordingly by us to be loadable modules, and we’ll provide resources to the users for migrating their patches and the benefits of doing that, I think even some automated migration script might be possible to run on a patch to do most of the porting.

I think different front-end apps are inevitable here, our app was in development before MEC / ORAC appeared and we have our own goals of where we want to take the Pisound App in the future, ORAC has its own, and most likely even underlying frameworks we use would not be compatible, so not much options for code sharing.

If you’d like to run the current Pisound patches on other platforms than RPi / Pisound - the only dependency is the pd-blokas externals package which is available here: https://github.com/BlokasLabs/pd-blokas - just build it for your platform of choice, add the binaries to path, and put the abstractions from https://github.com/BlokasLabs/pd-blokas/tree/master/debian/usr/lib/pd/extra/blokas in.

What we could have done better is discuss with you on how would you like our use of MEC to be presented in the documentation, press release and the app itself, this is a learning experience for us, so we hope to do better, and we really value your great work.

thetechnobear · June 23, 2018, 11:49am

MEC/Orac is open source, this is so that others can take it in directions they choose without restriction (well within GPL terms).

Here, I merely wished to express my goals and so the direction I am taking MEC/Orac , I guess, what I had hoped might happen with collaborations.
but these are just that, hopes and desires, some of which would not be met for a variety of reasons, including different goals - thats cool by me.

also, I think Im probably a bit guilty of ‘mixing roles’ here…
A) the developer of MEC/Orac, with a desire for multi platform and collaboration
B) an early adopter/owner/user of PiSound (and an advocate)

I think (B) sometimes creeps in - as an iOS user, its pretty hard for me to appreciate the ‘software value add’ , as it doesn’t run on iOS, nor my desktop.
so I only use the hardware, no blokas patches nor software (except driver of course) - but perhaps Im in the minority here.

yeah, Im guilty here, I didn’t really think about it.
I use my rPI with PiSound, so perhaps I focused a bit too much on it, and collaboration around it, and expecting you to highlight MECs neutrality was unreasonable.

Obviously, I should be the one making it clear you can run on any rPI setup, and perhaps feature on the Orac 1.1 release videos.
(Ive since bought a second rPI3+, so i have a rPI with a HiFiBerry DAC+, and I could also present with a USB audio interface, so this should help)

Similarly support/discussion of Orac (on release) might be better on the rPI forum, to show neutrality.

None of this means I will not continue to recommend PiSound, I will, as I think its currently the best audio/midi interface for the rPI.
However, I don’t want to exclude (for no reason) rPI users who already have valid hardware, and lead them to believe they need to buy something extra to use Orac/MEC.

anyway, thanks for helping clarify my thoughts, and discussing your viewpoint, all very useful.

but now back to coding… Orac 1.1 wont write itself, lots of new features still being added and new modules to write!