Compatibility with Organelle Patches?

this two questions are kind of related, so i’ll answer the second part first.
basically in 3.0+, patches are now able to draw arbitrary graphics to the 128x64 screen, using various new api calls the screen.
(many of the other changes are to do with how patches are started etc, which are not really relevant to rPI/PiSound)

the primary problem (esp. as a community endeavour) is that the rPI/PiSound does not present a ‘common platform’… whilst one can argue you could use midi controls to replace the knobs.
it lacks any kind of solution for the display.

the only common solution that exists today would be to use a HDMI monitor/screen.
but thats pretty bulky for what only needs to be a 128x64 screen, so its not something Im interested in.

of course, you could design some hardware yourself that uses one of the freely available oled displays, its not a difficult hardware project, then you could write an interface layer to that.
its not that difficult a project, though you probably need to be able to at least read C++ code, to be able to check the Organelle implementation.
the reason I’ve not been interested in this, is few users would have the necessary hardware to run it, so its of limited appeal to a community.

there are some other projects, that are working in this area - though none are released yet, i don’t know if they are weeks or months off.

btw, none of this is a criticism of the rPI nor PiSound, its just these are DIY solutions, they kind of expect the user to build upon them, to build something tailored to their requirements, to use what they have.
whereas the Organelle is a fixed format, an instrument… so you can easily develop for it, since you know even user has the same thing.


it was this lack of a common UI for cross-platform development, that led me to create Orac.
Orac takes a different approach, its says the common thing between patches is that you have a bunch of parameters - and then leaves it up to the platform to decide how to deal with these.
(hence we can have a remote interface on the rPI, and let it be ‘headless’ still - which is what every piSound owner has :wink: )

What is your ultimate goal?

if its just to have more patches, or more capabilities…
you could look at moving some of the Organelle patches you like to be Orac modules - this I’ve documented pretty well already.
this would be a community effort that all Orac users could benefit from, on PiSound, Organelle or other platforms - this only requires some basic PD experience, and there are a number of developers already doing this… so a community that could help you.

if you’re a low level coder (C++) , then you could also contribute to the development of Orac.


as for using open source code… thats what its there for.
just respect the license terms (read them!) , and make sure you credit and link back to the original project.
depending upon what you’re exactly doing, will depend on the best way to proceed.

Currently Pisound App is rendering the parameters provided by MEC (Kontrol OSC interface) on its own and allows to control them. We don’t have any display protocol implemented in the app, but we might add that in future versions.

1 Like

maybe just an oled display?

I think this could be really helpful. There are many people trying to make a diy kinda organelle thing with an external midi controller and probably installing orac, you would just need to buy an oled that can be connected using i2c in the pisound extra header pins.

I’m not sure how difficult would be to port the new display API that draws arbitrary graphics, or if it would make sense to emulate (though they look nice :slight_smile:), but at least those four screenlines.

What steps would you recommend to achieve a minimum working patch w/ a generic oled 128x64 display? I don’t have much experience with pd, but I guess I could make an OSC client in python or something and understand how it works to send them to the display. Should I need that routeOSC or MEC? but not sure how to join all the lego blocks.

Organelle team open sourced a desktop mother version and I guess you’ve based on that one to make the Norns version of ORAC?

nope…

I wrote the Norns version pretty much from scratch,
the Fates/Norns display appears as a normal unix framebuffer, so i write to that using cairo (libcairo2), with this I created an API (NuiLite).

For Orac, I then interfaced this to my MEC software.

However, for Pure Data
I created a Pure Data external based on NuitLite.
and as might have seen in the video I made, I then managed to create my own mother.pd which used this NuiPd external.
(you can see this , at about 15:00 in this video)

this was however only a ‘rough’ translation of mother.pd for demonstration purposes only, not what I would think of as a full emulation - simply because its you’re using encoders (like norns) you might want to adapt a patch to use them better (i.e. not as virtual pots)

also… the newer C&G patches are now using a lot more graphics primitives for drawing etc, so thats alot more mapping that just ‘screenLine1’ etc. over time I’ll add similar primitives to NuiLite, but for now it was not a priority.


could I do the same for an old 128x64 display, sure… but this would have to make assumption on how its wired up (e.g. which pins are used) , also it doesn’t answer the question of how to replace the pots or the encoder the Organelle has - even then … how many users would use this … 5, 10?

the reason for doing UIs for Organelle and Norns, is they have larger (not that big I admit) user bases.
similarly the remote interface for Orac, meant a large number of users with just a rPI … nothing else, could use it.
like everyone, I have limited time to commit to these projects (which are free/open source), so I try to use this time to benefit as many people as possible…

of course, all this said… if someone wants to do the development for the oled, then id be open for discussion on how its best done, so it could be merge into the main orac/mec code line


one interesting thing for someone thinking about development in this area,
the Organelle-M is based on a rPI and the screen handling for its display is actually now done on the rPI ( it used to be done on a separate microcontroller) - so if you wanted to, I suspect much of that code would be usable for your purposes.


of course, Im hoping one day @Giedrius/@Pranciskus might one day looking into create a ‘full rPI solution’ using PiSound for audio side, and then adding a bunch of encoders/buttons and screen - given the great job they have done with PiSound, Midiboy, MidiHub and PatchboxOS- I think they could come up with something really exciting :slight_smile:
(Blokas if you do, it be great for it to have some CV I/O too :wink: )

1 Like

I understand a bit more now

That was a big challenge, never coded something to display in a linux framebuffer. You’ve just taken the mother patch as a design API interface, but NuiLite does all the heavy stuff. I’m still a bit confused about the purpose of MEC, does it work like an osc bridge?

I’ve taken a look at the organelle os source code (they put it on github, nice!) and right, they seem to be using the cm3 gpio pins for the oled, to read a mpc3008 for the adc inputs, and a shift register for the keys.

Anyway, I really love the direction in which instruments like organelle or axoloti are going :heart: despite I think the organelle is a bit expensive.

I’m not sure if I’m capable of fully building a new instrument both hard/soft, but as a developer I think a lot of people would be opened to any kind of instrument which provides an API layer to access its hardware, and lets you play with it. This part of the video, and the following tutorials, are a great example of that

So when I did the Orac on the Organelle, I put the display logic and code in an external inside PD.
But on later on reflection, I decided it was better to have that code in a separate process (mec) that could support many different devices simultaneously.

The next step will be to make it so that I can run the same code either within PD ( ‘in process’) or within mec ( ‘out of process’)

Really it’s all just about flexible software design/architecture :slight_smile:

Hi everybody. I hope everyone is doing well, and safe.
I’m a total noob and don’t own pisound yet, but before buying it I have a question… Is it possible for a total noob like me to install some of Organelle patches (I’m mostly interested in granular samplers/effects) on PiSound?
Sorry if I’m asking something already stated, but I’m not getting much of the discussion.
Thanks, stay safe,

Tommaso

I’m currently trying to sort myself out a hardware (screen, pots and keys) solution…

The direction I’m going (and my thinking is for open source use) is to use off the self components. Currently looking at a Arduino Micro for all of the midi controllers and keys (via a multiplexer), and the screen and navigation through an Adafruit OLED screen (with buttons) set up.

Now, I’m currently using a cheap USB DAC for Audio, which works fine for now, just trying to get my head round the screen and menu navigation currently.

I think I’m going to take inspiration from @Giedrius and @Pranciskus’s midi boy sketch, but I’m yet to figure that out on the pi (as theirs is ATmega328P controlled).

Anyway, as soon as I have solid solutions, I’ll put them out there, and if anyone can help out or point me in the direction of anything useful, I’d appreciate it!

Thanks to all these amazing people contributing to the community!

Nick