Load and store samples from within a patch

The OpenPanel object for loading wave files into a patch, ist only working on the Organelle, when using directly in Pure Data, when opening the patch on the HDMI screen.

Is there a corresponding object in the Organelle firmware, to achieve the same functionality from the OLED screen of the Organelle?

Some kind of file browser for wave files?

That would be a basic functionality to loading and storing samples from within a patch and very much needed, to turn the Organelle into a true sampler.

You can use the folder_list external. You can check out my Loopy or Converb orac modules for examples for navigating and loading files using it

2 Likes

Thank you, very kind!

Would it be possible for G&G to create tutorials to show, how to use objects in Pure Data to select samples (wave files) from the OLED screen menu?

My recommendation would probably be to crack open some of their patches they’ve made and has functionality you like and try to reverse engineer it.

That’s basically how I learnt Pure Data :slight_smile:

1 Like

I installed orac and then downloaded loopy from patchstorage. Then I pressed „install loopy for orac“ on my Organelle.

But I am no able to find loopy within the orac system on my Organelle.

You may need to go into your Organelle web server and place it in the /sdcard(or /usbdrive)/media/orac/usermodules and then unzip it there

1 Like

Ok, thank you. It works now. I found the page “samples”, where I can use pot1 for sample source and pot2 for sample select. Then in the bottom line I see the path and the sample names to select.

This I understand. In the folder “sdcard/media/samples” I can see three folders kit-1, kit-2 and kit-3. In my HDMI monitor file explorer of the Organelle, I copied a sample, renamed it to test.wave and then I was able to select it with pot1 and pot2 on the OLED.

But one thing was strange. With pot1 I can not only select the folders kit-1, kit-2 and kit-3 but also more, like kit-4 to kit-10, on my OLED, but in the HDMI file explorer I see only kit-1 to kit-3.

Are they hidden?

I’m not quite sure? Ideally you should have kit-1 - kit-24 and then the samples folder is kind of a catch all folder for any other samples. You also may have encountered a bug lol

I don’t think it’s a bug. But in the loopy sample select menus I can see more kits folders then I can see in the file explorer. I will make a screenshot later.

Anyway, I will start to analyze your program. Pd patches can be overwhelming and intimidating, even if you are a software developer for - let’s say - JAVA or C#.

At the same time, when operating the organelle patches (like loopy), I am feeling the same way: the wooden buttons with not labels, very simplified and cryptic menu structures, no documentation: Not so easy.

Compared to usual synthesizers, the Organelle has a steep learning curve.

To my knowledge, in the gritter&guitari patches there is nowhere a patch that uses your kind of sample selection. They all use fixed sample names, hardcoded in PD. They have a YouTube Video called “Critter & Guitari - File Management with Organelle - OS 4.0”

So, that’s the way, C&G wants the user change samples in their patches. That’s indeed very simple, but I wish they would provide objects and make a tutorial on how to use these objects, to select samples directly from a menu within the sampler patch.

C&G sometimes have a strange product policy. For example regarding orac. Orac was not developed by C&G, which is strange enough. It was developed by a private guy. But it was not made a permanent and integral part of the organelle. Instead it has to be installed separately and the wooden keys that are used to configure the modules, are not labeled. The Organelle could be a much more user friendly and less cryptic device, because the basic idea is very cool, but the practical implementation is unfortunately largely in need of improvement.

The workflow is often intimidating, overwhelming and cryptic. Even for me as a software developer (VB.Net, C#, Java), the whole system is difficult to understand and every step is time consuming.

The screen should be bigger and there should be more tutorials and ready-to-use objects to create menus, file selection, waveform display, and so on. Every potentiometer and button should have a dedicated screen, like the Akai Force or the new Tempera. This would make the workflow easier und more intuitive.

1 Like

I will try to document more of how the sample selection works a to z for you as for both of those responses I was away from my computer/organelle and wasn’t able to give a detailed response.

One question I have is are you new to the Organelle and it’s conventions or are you new to Pure Data in general? Most of my complaints in regards to work flow is more on Pure Data and not necessarily on C&G themselves.

I do understand your frustration with the fact that Pure Data is a definitely odd language when compared to typical text based languages with syntax highlighting, autocomplete, using ctrl f to find, and other nice features. It also doesn’t help that everything is just a black and white box with black lines connecting everything which can make everything look the same. A couple of those have been addressed in Max which I have been using more of but I still like some conventions of Pure Data as it is one of the only programming languages I feel extremely confident in.

In regards to your complaint about how there should be dedicated functions like the Akai Force and Tempera, these devices were designed to serve specific musical duties and it is a little unfair to compare it to the Organelle as it’s goal is almost the exact opposite. The Organelle is basically a Raspberry Pi with an audio interface, microphone, some buttons and knobs, sometimes a speaker, and MIDI implementation that can interface with Pure Data. That’s really it. It’s daunting but I personally find it exciting but it does throw you to the sharks more so than other established languages with extensive documentation like the ones you mentioned.

There is still a wealth of resources that span the last decade on Pure Data and I can definitely link you some that I have found helpful in learning it but the other great thing is you don’t have to do it the C&G way of making pathces. I know there is the O-Knob system which was developed for the reason to address the issue of a ready made page and knob handler. They also have made a Graphics Demo patch that show cases how you can interact with the OLED display and it’s well documented.

There’s no limits but at the same time C&G aren’t really in the business of giving lessons on Pure Data which is I think is primarily responsible for the weird and wonky ways of working. I will say some of the ways C&G have implemented their shortcut system and other code can be difficult to understand as they employ lots of sends and receives so it requires bouncing through different subpatches to find what is going where. They primarily use their in house ways of doing things to create instruments and creative effects for their own stuff but I hardly ever use it except for some useful code and abstractions they’ve made every once in a while.

One more thing I’ll mention is in regards to Orac and why C&G don’t lean into it more and produce more content on it. I haven’t spoken to Chris, Owen, (C&G) or Mark (Orac creator) on this so this is all speculation. C&G have made content on how to use it and have featured Orac, Orac 2.0, and more recently Orhack. It’s not extensive and Orac is deep. Quite deep. But they have made an effort to bring it into the Organelle ecosystem. It also has it’s own conventions that it abides by and uses. Not to toot my own horn but I am pretty familiar with it so if you have questions, feel free to PM whenever.

I also don’t expect C&G to continue work on Orac as it’s GPL and they have no financial incentive to work on it as they can’t commercialize it (to my understanding, not a lawyer) unless they believe that is what the Organelle should become and will help sell more product. I don’t think that Mark would be comfortable if C&G hijacked his work and made that the base of the Organelle ecosystem, nor would I think they would even want to. They clearly have tons of fun making their own weird creative patches of their own and have been hard at work creating new and innovative instruments like 5 Moons, Eyesy, their Microphone, and more!

Last thing I’ll say is the most powerful aspect of the Organelle is the community aspect. I usually try to always pop in on a forum post and help out whenever I can and there are many others who help too! I will be sure to address your specific concerns on how I have dealt with the filesystem navigation with screenshots when I take a closer look at what I did again lol.

1 Like

Okay I annotated and commented on all the different parts of the sample loading process. This is taken from Loopy but the general concept is the same for some of my other patches that utilize sample loading like OracLoops/Octaloops and Converb. The process is as follows. First we need to define an array which the sample will be stored in. We also will declare and add the soundshare library to our patch. The main listing and spitting out of path names is handled by the object soundshare_select. The guts of it are included below.

Based on the sample_src parameter, it will add the first part of the path and will choose the directory. These are preprogrammed and can be changed in the pd source abstraction. This is probably why it is pointing to kit’s that don’t exist because the program doesn’t care if it actually exists or not, it is just a message. After the source has been defined, folder_list spits out all the files that are contained into a list. The list can be scrolled through and different samples are selected with the samp_select parameter. When a sample has been chosen from the list, its path and name are output from two different outlets.

The file path gets sent to a read object which is sent to soundfile_info. We unpack it and use the 3rd outlet to resize the array so the array contains the entire sample. Finally we also use the path to send to the open object which is output to a readsf~ object which will finally read the soundfile into the array. From there you can look into various ways to play back said file. I hope this has been helpful and I’ve included the abstractions as well if you want to incorporate it.

sampleloading.zip (42.1 KB)

1 Like

Hi T8R,

I understand, that the first part of the path is hard coded in the function block „pd source“, named „kit-1“ to „kit-i“. That means this file browser will not browse folders, instead it browses wave-files contained in prepared folders, that have to follow a fixed naming.

I understand, that’s better than nothing, but I ask myself if it would be also possible to browse folders, dynamic and free?

Beside the PURE-DATA programming, I have to learn the UI-programming for the organelle, even if the UI is very simple, it’s important to keep the workflow simple and intuitive.

Unfortunately I only know of the way of using prepared file paths :confused: It hasn’t been a huge problem for me though because even though there a limited number of source locations, you can still fit many many audio files in each directory