This was an early idea when we were working on the os. It could be incorporated right into the mother patch pretty easily. I think we didn’t end up working on it because we wanted to keep the mother patch as simple and low overhead as possible. There is also the issue of how to control it, having to navigate to a menu seemed a little cumbersome, but maybe not?
Its been a 2 year meditation for me regarding internal recording. The extra menu is worth adding a bit of complexity. What was the added cpu/ram load?
There are patches already that do recording of everything. Orac / Orhack and s3rquencer (probably amongst others) do it. I think mother.pd is perfect the way it is providing (just) a full interface between the hardware and puredata and leaving all functionality to be dealt with in the main patch.
But I also get that the only way to ‘suddenly’ add recording capabilities to all/old patches is by creating a new (non default) mother patch that could be added to the desired patch directory. but anyway its tricky to choose the action required to start the recording since some encoder / key combos might already be taken by some patches.
There are patches already that do recording of everything.
I am open to correction, but of what I can see the only available universal recording patch is “capture”. Its buggy and abandoned.
Orac / Orhack and s3rquencer (probably amongst others) do it.
True. Those patches don’t address my consideration however. (how do the design principles of the stock organelle os translate into a global tape machine?)
I think mother.pd is perfect the way it is
I understand as a developer you enjoy a stable api. In balance, the everyday user has usability needs. The lack of a global tape machine makes it practically impossible to use the Organelle as a general purpose song writing device.
One of the things to have in mind is that the design principles of the stock Organelle (somebody correct me if I’m wrong…) was to be a very very simple to use machine with a keyboard, knobs, an extra button to record a sequence, and a display / encoder combo to switch patches very easily…
Newer more advanced features like multi page, multichannel or the ability to use several patches at the same time are either a community contribution or a later addition from C&G. Thinking of the organelle as a ‘General purpose / standalone song writting device’ seems more inspired by community patches than the original design principles of the Organelle I think… (The beauty of Open Source…)
Adding global recording to mother.pd isn’t difficult (Minutes…) but interacting with that, in general, (as Oweno already mentioned) now that there are patches that make use of the encoder would be challenging and messy…
little Issue nr 2 is that while you are recording to USB / SD there is a little tax on cpu / mem so if the patch you are recording is complex, with many channels and many effects, its very possible that you are gonna get clicks/ glitches…
I do have a master recorder option in my patch (apart from independent loopers that save and recall) but if I’m performing anywhere or if I’m recording to make a video, I never use my integrated master recorder even though the chances of glitch are very very low. I use either a zoom recoder (that also records video) or a stereo soundcard connected to my phone.
Ah!, issue nr3 is to How to stop and when to stop a recording, because if you forget to stop, recording might get corrupted and lost or if you remember late, you might end up having gigantic files in your usb.
Servandob, you write that you have “a master recorder option” in your patch, what patch is that? I am very intrested in the posibility to be able to record from every patch, like a global master recorder somehow. That is very much missing in Organelle!
It’s called s3rquencer. I will put it soon in Patchstorage. (+ link here and in the forum).
In Gumroad I have a ‘contributive’ more complete version since I spent thousands of hours working on it but if you wait, you can test the light version before… (It also has the master recorder mechanism)
Also… If you look for it… Somewhere in my page there is also a free ‘pc’ version of S3rquencer. Now a bit outdated but with similar specs / principles…
Hey @sefu thanks for starting this thread. The themes in some of the comments above reminded me of experiments with the HID external I had made a while back, and never shared.
My idea is to address the “control issue” by using an external USB device, like a USB QWERTY keyboard, to control meta functions on the Organelle. I have modified the HID external from pd-extended so that it can ‘grab’ a device, like a keyboard, gamepad or mouse, exclusively.
As a result I have created a mod called “RecBside”. It’s a lightweight internal recording tool that can be dropped into any basic patch to add a recording function. You press spacebar on an attached USB keyboard to start/stop recording, and it creates sequentially numbered recordings on your SD card from the Organelle’s output. (It’s very basic for now, doesn’t even include a separate recording level.)
(Essentially it’s a slightly modified mother.pd plus support files that can be copied into patches that you want to record.)
My idea is not to create a full-on song-writing tool, or OP-1 style tape machine, or mini DAW, or multitracker or anything like that.
But I think it would be very interesting (and compatible with the spirit of the Organelle) to at least have some way to move fragments and recordings between patches more seamlessly. E.g. you make a loop or synth sound you like, grab it, then you could open another patch, like a granulator, and play with it, then open the result of that in another patch and re-record layers on top. My philosophy is that “copy” + “layer” + “resample” is super powerful and fun, and it would be great to help patches on the Organelle work to share resources and fragments internally (without having to click around the filesystem). RecBside is my personal start along that line of thought.
It’s still under development, but if you want to try it out you can find the source code here:
I’d appreciate any feedback.
But if you need an external keyboard to operate it you could also need a smaller external recorder, would probably be easier or? It would be so practical to not having to use something external at all. Just click some key combination that never being used otherwise to start the rec. Like f.e aux and pressing the selectbutton at the same time.
I agree that it would be practical to not need something external at all. The problem is that if you listen for ‘aux’ and ‘select button’ at the same time, the OS still sends those combinations to patches as individual keypresses, so they might cause activities in patches that listen for ‘aux’ individually, for example.
External keyboards don’t have to be super-impractical. There are so many form-factors available, even USB keyboards that consist of just 4 macro keys, or even just a single key. A keyboard can also be wireless (with a 2.4ghz USB dongle). So you can go big or small or tiny if you want.
But how many patches have commands that use f.e a downpressed select button and the last B-key? I know none and if there was one patch I would gladly live without the possibility to record from exactly that patch.
Let’s think through this methodically. Hopefully I understand correctly what you are suggesting.
Imagine that a user wants to press “select” + “B” as a key combination. When they do this:
- The “select” event gets passed to mother.pd and passed along to the current patch as an “encbut” message.
- Separately, the “B” key event gets passed to mother.pd and passed along to a current patch as a “notes” event.
To implement “select” + “B” as a key combination, but also keeping these buttons for their separate independent functions , you would have to intercept these events, and delay them for a certain amount of time, to see if the other key is going to pressed at the same time. If, say, “select” is pressed on its own, then released, then you can send the “enc” event to the patch, after this “waiting” delay, to cancel a possible “select”+“B” combination. Similar, with “B”+“Select”. To put it another way, mother.pd can’t predict in advance if both keys will be pressed at the same time.
Hopefully this explains why looking for key combos could introduce a latency in any patch that uses the keys in question individually. This may or may not be acceptable as a design decision.
It wouldn’t be hard to implement - if you want to experiment using RecBSide as a starting point, you can send
stop messages to
rb-RecControl from anywhere in your patch or mother.pd to start or stop recording, based on any input you wish
A delay wouldn´t be a problem I guess. Just start to play for the recording after that delay.
…so all patches would have a delay - even if you weren’t trying to do key combo.