New Combo Patches


We just put up 4 new multi page combo patches. These combine synthesizers, samplers, effects, and sequencers in a various ways. Check em out here!

They also feature a new effect chooser page, you can select 1 of 13 different effects.

What would you try with 2 Organelles?

Wahooooo! New C&G patches :smiley:
AND they feature polybeats adaptations!!! So excited to try these.

Edit: They are fantastic, I will be using these a lot. I bet you guys had fun with your multi-organelle link setups and the polybeats ones.


Definitely checking these this evening


@oweno Does the Basic Sampler in BS FX PB have the same Sample-in function or does the user insert a sound.wav of their choice into the patch via the directory? Having a spot of trouble getting the aux button to sample in… Though could just be me.


Yeh same here. Hoping that sampling from input is possible. Too many organelle sample patches where this is strangely left out :frowning:

This patch felt kind of a backwards/sideways step in some ways tbh. Would have been killer if it could sample from inputs and have a different sample on each key and then select which ones to sequence (more than one simultaneously…). And also being able to stack the fx would have been cool. Didn’t check cpu while it was running, maybe not possible due to that?


lol come on man


@wannop yeah this one doesn’t sample in, but it could. Right now the aux button controls the sequencer start / stop (hold it down to erase btw) on every page. But maybe on the sampler page the aux button records in would be better?


Lol at what? It’s cool that people are making/sharing patches, super grateful. Was jus sayin :wink: Sampler patches that can’t sample, on a unit with inputs… Just seems like an obvious thing to throw in patches if the person coding is able to? Wasn’t being a dick about it, I appreciate the patches, just wish I knew Pd and could tweak em…

Edit - didn’t mean to come across as complaining. Seems like I’m one of only a few people on the forum that’s not dabbled in PD and able to fine tune patches themselves. But there must be a ton of users/potential owners out there in a similar boat? I dig the Organelle a lot so far but coming from a non-PD proficient angle, I can see why some people might be kind of underwhelmed/frustrated with a bunch of the patches. When I’m making feature request comments on a patch like those earlier, it’s only cos I wanna see the unit progress and be a success for C&G. I don’t really see it as any different from making feature requests on any other piece of hardware? Not all customers are gonna have time/skills to learn PD so it’s probably in C&G’s best interest to really strech these patches as far as they can imo and attract a bunch more ‘regular joe’ customers…

Like instead of so many patches. Less would often possibly be more. A single patch with sampling per key, option of poly beats sequencer or normal sequencer, stackable fx, saveable/browsable/loadable samples, save able/browsable/loadable presets (save as new seems like an OK workaround for this tho?), midi in/out… If that kind of bread and butter patch flexibility framework was locked in as standard then anything on top in various iterations would be icing. Obvs wouldn’t be neccessary/optimal in ALL patches, but most sampling/sequencer ones at least…

Saying all that, these new ones still look fun, thanks @oweno :slight_smile:


as always the new C&G patches are great fun, and I love the new flexibility on the effects… light on cpu too :slight_smile:

@oweno small bug … PD is case sensitive on some filesystems… so when you refer to ./polybeats/Polybeats, it must be polybeats/Polybeats.pd not polybeats/polybeats.pd

pure data 0.48 issue

as an aside Ive found with PD 0.48 some of these patches are crashing if alsamidi is enabled.
not sure if this is an issue with the patch, or a bug in 0.48. since:

  • the patch works with alsa fine on 0.46
  • the patch works fine on 0.48 without alsamidi
  • majority of other patches work fine on 0.48 with alsamidi enabled.
  • the patch works fine on 0.48, with alsamidi , if you enable the GUI

ok, there is a bug in 0.48 since it core dumps PD… but Im not sure if the patch is some how ‘provoking’ this, given others are fine… given the last point, I’m assuming there is some kind of race condition.

EDIT: ok some good news (kind of)

  • this crash is the same crash as with the other CG patches thats crashed when I first build 0.48, so nothing new.
  • Ive just built 0.48.0 on the rPI3 and it crashes in exactly the same way with the same patches.
    so it seems likes it a general 0.48.0 issue… the advantage of it crashing on the rPI3 is I have a working GDB environment :wink:
  • i tried with alsa setting in .pdsettings and its the same issue, so its not a command line issue.

I did also check puredata mailing lists, and there appears to be no mention of this bug.
I guess another thing to try, is to see if this is reproducible on a Linux X86 build, so we can determine if its a general alsamidi/linux issue, rather than ARM specific. (I suspect its not arm specific but you never no)
The other thing we can try is removing bits from the patch to see if we can stop it crashing i.e. a workaround.
( note: I ran the patch on the rPI without mother.pd, so we know its just in the patch not some combo of mother.pd and patch)

I think this is pretty important, as for the next release, we want to move to 0.48, and also I think we should be considering moving to alsamidi as the default midi implementation.


funny I just noticed it when working on this patch. I was confused it was working because I assumed Linux would sensitive to it.


and interesting about the 0.48 stuff. thanks for checking that out. I guess we should whittle the patch down to find what is causing the issue. it could be a bug in 0.48, but might just be something done incorrectly in the patch.


its down to the filesystem, fat is insensitive ( as on USB stick), but on ext4 is sensitive.

To confuse matters there’s a difference between sensitivity and display e.g. Some filesystems display upper/lowercase but are still case insensitive.
(It’s all historic, and down to backwards compatiblity)

PD doesn’t see any of this , it simply takes the abstraction name and adds .pd :slight_smile:
( there’s a similar issue with externals)

0.48 yeah will check, easy enough now I’ve a good idea where the issue lies.


thanks @Generationloss, always good to hear suggestions, keep em coming. The big challenge I see making patches on the Organelle is striking a balance between features and usability. Packing in a lot of stuff can make it hard to grasp for the ‘average joe’ user. I like the idea you mention of smaller number of patches that do more, and this is something we have been working towards as well. Then once you learn how to use one, the others follow the same pattern, so I see lots of potential in this area…


@oweno ok, Ive found the issue with 0.48.0

in master metronome (in arp and your new patches) , you are sending out midi clock , this is where it crashes…

my suspicion is, this is happening during the loading of the patch, probably before alsa has been setup/initialised correctly.
(I assume, it doesnt crash when running the gui, as the patch is taking a little longer to start, so by the time the metro starts alsamidi has been properly initialised.)

definitely a PD bug, but Id suspect a workaround/fix is to use a spigot and only open the gate a short while after the patch is loaded. (milliseconds will do)


does this mean its possible to have a combo patch that has a polybeats sequencer with drum samples on one page and then a synth/ effects processor/ whatever on another page? or can the polybeats sequencer only be used to sequence whichever synth or sampler on the other page?


Totally possible, and something we’ve been working towards with these new combo patches. We redesigned a bunch of earlier patches to make them more modularized so it should be easier to construct arbitrary combos. overall CPU might start to be an issue, and also the challenge of fitting it to the Organelle’s controls in an intuitive way, but yeh definitely possible


@thetechnobear right, the filesystem, makes sense now. I’ll update.

So the midiout is the issue. good job figuring this out, I guess it fires a message out immediately when it loads, so we can just add a little delay like you mention. the good old delay before starting never dies…


yup a 30 msec delay fixed it for me on all patches.


This all sounds great (if worrying to my future bank balance if a new more powerful Organelle being planned…)

For me, CPU-heavy stacking of effects/patches less important than capability/interoperability of individual patches.

So a standard sampling/recording module capable of being incorporated into most/all sampler packages to enable on the fly sampling to populate sound files in that patch would be awesome.

Similarly a “record and output” module enabling a nice soundscape (say generated by Moth or whatever) to be grabbed for use in another patch (say a looper or sampler) would be cool (perhaps there might be the option of redefining one of the periferal keys as an Aux 2 for that purpose?)

Whatever, am only a few days into my Organelle and blown away by what a few people in the community are creating. Amazing stuff.


BS FX PB is updated to allow recording sample using a foot switch: