Hi @ronsum and other pd lovers!
Do you have a “standard procedure” for porting organelle patches to zynthian or you simply tweak the patch until it works?
I would like to port some specific patches from the organelle collection that i always found very fun to play with. To be more specific:
Of course, if some of you want to help me with this, i would be very pleased 
Thanks!
Hi @jofemodo,
I found a quite universal workflow integrating organelle patches into zynthian, as long, as they only use standard 4-knob, 2 switches and an expression pedal (volume also).
I tried it with Granular Freezer:
(see below for a more recent patch)
It is still just a rough experiment, but does what it should do.
If I found more time, I will try the other organelle patches and describe the workflow later.
Regards
EDIT: re-uploaded the patch, because volume was to low.
My zynthian doesn’t have audio in so I couldn’t test this. You may need to make some changes to the yaml.
Guitar2ARP.zip (179.2 KB)
I also did Granular Freezer but just noticed @gitnob already posted one for it.
I am working on Tapey now. CZZ-multi uses multiple pages and will require a bit more work.
You are amazing guys!
I will test tomorrow
Thanks
As I said previously, my Zynthian doesn’t have audio in so I couldn’t test the “Record Samples” feature. Everything else seems to be working.
Tapey.zip (552.0 KB)
It works super nice!
I just added a second “latched” toggle for the freeze feature.
Granular_Freezer.zip (14.8 KB)
Thanks!
Hi @jofemodo, good to hear. I just was reworking it also (see below).
To your question about the general workflow…
Organelle is working like this: There is pd patch called “mother” (nice, like it). This is the API frame and uses message and audio signals as interface. They are called “inR~”, “inL~”, outR~" outL~" for audio signals, and “knob1”,“knob2”,“knob3”,“knob4”,“vol”,“aux”,“fs” and “exp” for controller messages and “notes” for midi messages.
If you load a patch, the patch receives these messages and works with it.
I wrote a draft version of a zynthian specific “mother” patch.
organelle_mother.zip (14.0 KB)
Simple patchstorage patches (which do not use more than one screen) should be able to work with this mother patch.
But if it uses more than one screen, this is usually done by holding the aux button of organelle and pressing a dedicated key on the keyboard. This is somehow different to zynthian, because there can be more screens.
For simple organelle patches: Unzip the mother patch in an custom directory.
Place the content of the patch from patchstorage anywhere inside an arbitrary folder within the folder of the mother patch.
Replace the abstration “RegularPatchstoragePatch/main” with the name of the arbitrary folder name, like “YourChoosenPatchName/main”.
Set the initial values which feeds the initial “pd initPatch” patch.
After this, you adapt the zynthian.yml file.
You’re good to go.
@jofemodo:
Question 1: why exactly is it that only one instance of pd can run within zynthian. Is it the jackd name, which can’t be changed?
Regards
BTW: I reworked the GranularFreeze patch a little bit (again), because the foot switch and aux were working like triggers and not like switches in the original organelle patch. With zynthian, it’s a little different.
Granular_Freezer.zip (13.9 KB)
OK! I will try the “mother patch” with other examples from organelle collection.
Looking forward, it would be nice to send-back to zynthian (using OSC, for instance) the “ScreenLine” & “Led” messages, so we could display this in a “Organelle UI widget”.
In the other hand, we have a problem with the “external binary libraries” (i mean things like abbleton link, clocker, clockfix, etc.)) that are compiled for ARM 32bits (organelle) and we would need to recompile for ARM64 bits. I don’t know where is the source code for these libraries. Do you?
Simply a design decision to simplify initial implementation. We could release this restriction if users think it’s convenient. I wouldn’t be too difficult. The real problem is in the “MIDI” side, because pd doesn’t support jack midi and we need to use the ALSA bridge for this.
Regards,
Well, a kind of organelle UI could be fun, like it. Not that I have an organelle, but I’m a BIG fan of pd. Sending OSC mesages shouldn’t be a big thing.
Perhaps together with @ronsum we could write a more extended zynthian “mother” patch.
But zynthian UI programming … I tried to understand once, but skipped in absence of introductionary manual or something similar.
The ableton link abstraction? This one?
“Deken - Pure Data externals Database”
It seems to be there … I am off my box atm, hence couldn’t try.
Probably the other abstractions are also available through deken.
In which patches are those abstractions used?
Regards
I would think it’s convenient, but I have in mind that there have been some troubles with it. Could be real pleasure to have a zynthian box managing custom pd patches in different chains… hot dreams… 
Regards
I compiled the clocker and clockfix for 64-bit. I must leave now for an appointment, but I’ll share them later today.
I examined an organelle patch and found, that there is a special treatment of different tempo senders (ableton, midi, internal). For example in Ypolimenti, there is the metronome patch which tries to get the tempo information (syncing too) from ableton, midi or at least from patch internal clock.
The problem with this is, that, regarding the zynthian treatment of clock information, this is a parallel treatment of tempo information. I don’t think it’s a good idea to just implement this.
The midi tick information is read by midirealtime in the patch. Are the midi ticks reaching the puredata instance? I’m not sure.
IMO the only instance for tempo information should be zynthian’s clock, which is jackd’s clock IIRC.
clockfix is necessary for smooth tempo changes, and midiclocker creates an internal 360 ppq from a 24ppq from midi ticks. I don’t know what clocker does.
I don’t think it’s so easy to just implement original organelle patches if it comes to tempo sync, and multi screen patches. There should be some common guideline though. What do you think?
Regards
While driving to my appointment, I remembered 64-bit externals are in EuclidianZ. The author of clockfix changed the name to clockfill (It lot of research before I figured that out). You can find the 64-bit externals (clocker, clockfill and midiclocker) in the EuclidianZ/CG-Pd-Library/externals directory. I think the 64-bit abl_link~ external is already in Zynthian’s Pure Data. I noticed I left some files in the externals directory that cause the pd window to show errors when the patch is launched. Here’s a corrected version.
EuclidianZ.zip (1.1 MB)
Hi @ronsum !
The libraries now works nicely and no errors are printed.
In the other hand, the audio engine toggle doesn’t work. I’ve tried to find where “knob5” (cc93) is used in the “code” but i couldn’t find it. Perhaps you missed to save some change?
Regards,
Hi @jofemodo
Here’s what I did. I added knob 5 to turn off the audio engine (DSP). However, when DSP was turned off, the patch quit sending out midi notes. So instead, I added a toggle and spigot to interrupt the midi notes that trigger the drum samples to help reduce some CPU usage. Since adding a ninth controller would add another controller page, I decided to use the volume control to turn off the spigot whenever the volume is turned to 0, so knob5 wasn’t needed. I simply forgot to delete the knob5 object before saving the file. The toggle and spigot I added can be seen in generate-voice.pd
OK! Understood! I will delete knob5 and update the patch in zynthian-data repository.
Thanks!
Hi @jofemodo , hi @ronsum ,
regarding this question I for myself came to the conclusion, that it is unfortunately not always a straightforward process.
The most easiest part is the single page patch without tempo sync.
If it’s a single page, but tempo synced patch, it’s a little replacement procedure under the (mostly used) “CG-Pd-Library-Local” directory.
But if it comes to multi page patches, there are different implementations for this (esp. on patchstorage). These are not always easy to translate into zynthian’s controller framework. I.e. a >0.2sec press on “AUX” and simultaneously choosing a note in organelle is not zynthian’s selection procedure for a new screen.
Hence, a more advanced customization of these patches for zynthian are necessary.
Did you find a easy workflow for customization, @ronsum ?
Regards
Could you please give me a link to the source files? I want to build it also for desktop amd64.
Regards
I worked on several patches a few years ago to make them work with zynthian. As I recall, I made some abstractions to make it easier. I just need to find them again. Give me a day or two.
I think the source files for the externals are here: GitHub - owenosborn/clocker
Hi @jofemodo
I finally finished preparing CZZ-multi for Zynthian. The sequencer in the patch gets Stop and Play mixed up after recording sometimes. It seems to work okay when you turn the encoder slowly from Record to Play. That is difficult to do when using the touchscreen instead of encoder as you can easily go from Record past Play to Stop very quickly, and that is what causes the problem.
CZZ_Multi.zip (50.9 KB)
