@oweno @chrisk in the design principles of organelle os, what were the ideas regarding internal recording of patches? Was an internal global tape machine ever considered?
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?
1 Like
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.
1 Like
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.
1 Like
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!
1 Like
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âŚ
greetings.
S
.
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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.
1 Like
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 start and 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.
1 Like