Clouds - Gills version

Share Your Patch
1

thanks to Émilie Gillet (not Oliver Gillet) from Mutable Instruments for creating Clouds.

This patch is based on Clouds by Mutable Instruments.

There are 2 modes in this patch: granular or delay/stretcher.
Button S1 to freeze.
Button S2 does different things in different modes.
Button S3 to switch modes.
Button S4 to center pitch.

download here: clouds.axp (32.5 KB)

Page 1: Granular

Regular mode for Clouds. Button S2 triggers a grain sample.

  1. Position
  2. Size
  3. Pitch: Button S4 to center pitch
  4. Density: At 12 o’clock, no grains are generated. Turn clockwise and grains will be sown randomly, counter-clockwise and they will be played at a constant rate. The further you turn, the higher the overlap between grains.
  5. Texture: smears the signal
  6. Dry wet mix
  7. Spread
  8. Feedback
  9. Reverb
  10. Limiter gain

Page 2: Delay/Stretcher
Pitch-shifter/time-stretcher mode in Clouds. Button S2 sends a trigger signal and creates a clock-synchronized loop (when FREEZE is enabled) or stuttering effect – equivalent to applying a tempo-synchronized decaying envelope on the POSITION parameter. All parameters are the same except for knobs 4 & 5
4. Smear: smears the signal
5. Lpf/Hpf: low-pass/high-pass filter

3 Likes
Takeem - EVERYCITY ft Stanke (clouds' mix)
DIY cutdown Gills
2

I’ve always loved Clouds, the textures you can get out of it are absolutely stunning. I can see I’m going to have to build an extension for my DIY half-a-Gills to provide some more controls now…

2 Likes
3

Does the clds object work well? It seems to eat a lot of DSP. Might need some optimization (has been on my list)

4

Right now the patch works well, though I’ve tried the following routing and the DSP load went 100% quickly:
gills encoder integer output → logic/change → trig input for clouds

1 Like
5

I remember vaguely something like this happening here, too. The mutable range of objects was a quick port IIRC with the sidenote that “any bugs are your own”.

I started going over the code some time ago, other things got in the way but still on my list!

1 Like
6

Very nice, thanks for the effort!

It is quite heavy on the CPU, overshooting with certain parameter-values.

I took the freedom to make a Big Genes Version. It comes in two flavors. With and without pot-smothing.

clouds-BG.axp (34.3 KB)
clouds-BG-noSmoothing.axp (33.2 KB)

4 Likes
7

autotune with Clouds: Auto-cloud (autotune & harmony)

1 Like
8
1 Like
9

It’s too heavy on CPU for my Big Genes. All I get is fuzz :frowning:

10

Ha geez I always meant to give the clds code a good cleanup - the reverb inside the clds object for example isn’t always necessary and one could save quite some CPU cycles leaving it out

2 Likes
11

one of my friends is considering buying Big Genes for the Clouds patch. if Clouds gets optimised then I think a lot of people will want Gills & Big Genes.

1 Like
12

I had taken a look at clouds and it needs some work. I’ve done a bunch of MI ports to arduino for use with the rp2040 (braids) and the rp2350 (elements, plaits, rings, tides) so I was just thinking of looking at clouds since it’s next on my list for the rp2350. For reference: GitHub - poetaster/arduinoMI: Ports of mutable intstruments eurorack code to arduino. I based my work on GitHub - v7b1/mi-UGens: some mutable instruments eurorack modules ported to SuperCollider volker boehm’s nice ports to supercollider. His version of the MI eurorack sources is clean of hardware dependencies.

One thing that was evident on rings and elements is that even running the 2350 at 270mHz it’s tight. I reduce the the number of voices (4down to 2). I’ll go look at clouds now and will open another thread to ask about porting the rest.

1 Like
13

It does need some work! It looked like a quick port. Excited to see/hear your findings.

14

One quick question. It looks like all the objects in the contrib context, axoloti-factory/objects/fx/clds at 1.0.12 · ksoloti/axoloti-factory · GitHub depend/use the objects compiled with core? Is this correct?

Should also ask, I’m using the early prototypes (0.4, I believe) boards but I don’t think that should make a difference. Also still using the 1.0.12 axoloti patcher, so I’m not sure I don’t have to shift all that?

15

I think so. They added the mutable_instruments folder to the actual Core firmware because the MI code uses lots of tables and functions, best to save that with the firmware.

16

Ah, thought so. That makes it a real pita to work with :frowning:

I have one ‘aggregate” sluisbrinkie-eurorack-published/Mutable Meta Module at main · niektb/sluisbrinkie-eurorack-published · GitHub source at arduinoMI/MMM at main · poetaster/arduinoMI · GitHub

There, the libraries are all discrete (stmlib et. al.) but that sketch includes three and fits in under 3mb total. Is it even possible to do this in the contrib context?

EDIT: 1.2mb

17

I just finished the port for arduino and the pi pico2. I’d really like to not have to build firmware for this since I’m doing multiple modules and constantly making corrections. Rebuilding firmware every time would be a pita.

In any case, on the pi pico2 clouds runs really well but I am overclocking and running 2 cores.