Clds and Lmnts objects

#1

Mod note: I split this off to a separate topic

Clds.
Not 100%. The pitch is a few semitones and the density is a bit buggy.
Easy to assign the axocontrol though. (I used analog in to internal CC)

The Holy Grail ? (second reprise)
Axoloti release 1.0.12
#2

Hey just some feedback on the clouds emulation.

  • density >3 o'clock and <9 o'clock sends the cpu to 100%.

  • pitch does not span +/- octave

  • trigger sends the cpu to 100%

  • the reverb sounds noisy.

#3

yeah sorry pitch I forgot to scale, I'll sort out when I get time.

hitting 100%, yeah, some of this is expected... basically, I put a thin wrapper around both clouds and elements... so that the user could explore the codes limits. its not really meant as a strict emulation of the module.... though I appreciate a less raw version would be nice.
if you want to tame clouds or elements, for now Id suggest you put it in an subpatch, and place your own 'bounding' code around it.

I will take another look at both... as mention in the objects, they were still some what experimental.
(as aways, its a matter of finding time, to dig in further :wink:)

btw: can you post your axocontrol patch (or pm it to me) , I can then use it for testing.

also do you (or anyone else) have access to a real clouds/elements eurorack module, Id be very interested to discuss how it works... one of the issues I have, is Ive never played with the real thing, so at times its a little tricky to code the axo object.

#4

i have most of the mutable modules. i do plan to go through/compare them over the next few weeks.

clouds was a priority as i really like it. the object certainly sound clouds like!

to be honest i prefer the looping side of clouds. it would be awesome if you could extract that code and convert it over. you only got 8 seconds mono (4 stereo) on the original. the 8 second came at a quality loss/compromise.

it has:

  • loop start
  • loop length
  • pitch
  • diffusion
  • HP/LP filter (DJ kill FX)
#5

clds1.axh (19.3 KB)

#6

some good news - time to do a sync libraries ...

Ive just fixed pitch.
also added, playback mode , lofi, channels , bypass, silence.
playback mode gives you: granular, stretch, looping, spectral and last ...
(see help file)

I think theres still lots of room for improvements, if you PM me, then perhaps we can take this to email... what id ideally like to do, is to have some patches, that create a sound... feed it into clouds... and then we know what its suppose to sound like in both clouds eurorack and clouds axo.
this will perhaps help me narrow down where there are issues etc.
(same with elements)

I had a look at density, its not a simple matter of scaling, as its range seems to depend on other parameters (e.g. size) , I think there are few like this, which is why sometimes you can get it to 'weird' zones of parmeters.

#7

This is awesome!!!!!!

I'll do some further testing tonight. So excited about this now!

I can do comparison recordings. I have braids, rings, clouds, sheep, warps, peaks, tides... I don't own elements but I know plenty people that do... I have noticed with braids that there is artifacts if you tweak the timbre but I've not tested this thoroughly enough.

We can go PM but I think the comparison will be good for the public domain.

#8

At this stage I'm not really after comparisons, more an idea of how parameters are reacting compared to the original - so we can fine tune it a bit.

the dsp code is the same, it's just the paramter space is different so I think harder to find the sweet spots - but they are still there :slight_smile:

Anyway once it's improved, plenty of time for comparisons - and more importantly exploring unique aspects axoloti allows :slight_smile:

p.s I'll move this posts to a new topic, rather than derail the 1.0.12 topic too far

#9

ok, clouds got a revamp :slight_smile:

I read the clouds manual and got a better idea of what it does... and realised some of the parameters I was exposing were actually calculated.
Ive now fixed this ... so it now seems to operate correctly, and is also much less daunting to look at.

... so given I took some dials away, I took the opportunity add modulation inputs for those that have modulation on the panel ... this can lead to even more crazy fun :slight_smile:

#10

a slightly updated elements is now available too...

#11

k, last update for now...
clouds parameters are now bounds checked
you can now specify the buffer sizes that clouds uses... so you can much more memory than the original.

#12

hey! this sounds great, I just built my axocontrol and I am looking for patches that support it

how do I find this in the library?

#13

testing

so if anyone has an elements or clouds module it would be great if you could help me 'hear' the differences between the eurorack and axo implementations.

at this stage, even really simple patches will help me a lot.

the best way to do this is:

a) create a sound generator in Axo (e.g. sequencer feeding oscillator ) than can be used to feed clouds/elements. (preferably not samples, as its another thing Id have to manage)
b) feed into a eurorack module, to get a nice effect... photograph module settings (or right them down) .. try not to use any other modules!
c) feed into axo module, and try to get close to sounds you had in b.. like to be similar but not same settings on dials etc.
d) send me the picture and recording of eurorack, and patch.

you can do for as many/few patches as you like...
id suggest start simple, e.g. no parameters modulations, then we can move on, once we know the basics are there.

obviously (b) is critical, and is the main thing Im missing..., but also (a) is important as source material has big influence on the result, so its important we have the same in both scenarios

if you are doing things like gates/triggers into the modules again, better these come from an automated source.... ideally axo, but also you could use an eurorack LFO/sequencer that you match the speed/behaviour of in the axo patch for (c) - it just comes down to being 'reproducible'.
(getting users to play notes/samples/triggers cannot to this)

as I said before, Im not trying to get an emulation here, rather if the axo objects are useful, this is good enough for me. however, id like to hear the differences, just to understand a bit better whats going on, and more importantly if I make changes, Id like to hear if I'm getting closer to the module sound or not. (i.e. the eurorack photo/recording + input sound given me a reasonable test criteria for the axo objects)

of course, Im sure doing this will also have a lot of fun... I had a blast night playing with axo clds with various audio sources :slight_smile:

update

reverb noise:
ok, so Ive determined the reverb noise... seems to be 'deliberate' in clouds
its appears to be coming from it using a 12bit depth on the reverb engine, rather than the 16bit that is being used for Rings and Elements, if I switch it to 16bit, it seems to be much cleaner, and also I dont lose as much volume.

unfortunately I cant make this optional to the end user (it needs a firmware rebuild) , so not quite sure if to keep the character, or go for the cleaner reverb.
I will make a final decision once I hear eurorack examples.
(best way to hear the noise is help patch, turn reverb right up an density to 12, and texture to 0.)

perhaps I'll also record an example

sample rate:
I found the clouds code expects 32k SR, so Ive adapted to 48k ... doesn't seem to make much difference... but I probably need to test with different source material.

unfortunately these changes require alternations to the firmware, so will require a new axoloti release... or at least users take a copy of the firmware from GitHub.

#14

i've found with the reverb you need to drive the input harder and you get a better response...

anyway, noise is good sometimes

#15

i must stress clouds in particular is not a clinical/sharp sounding granular FX. it can sound "slurry" and lacks clarity.

this cannot be compared to vst type granular FX. there are artifacts

#16

I'll compare with the module when I can, but I find the noise just a bit too much in the current axo release.
I'll try to post a comparison at some point..

Ive been playing quit a bit with it this evening, with both synths and vocals, and its sounding good so far.

#17

a bit of play with clds and a bastl Kastle

#18

lmnts (and related objects ) have now been updated (sync libraries to retrieve)
please check the help file, as these contain important info.

if you read nothing more, then summay = only use string mode :slight_smile:

summary
(previously the modes were incorrectly labelled!)
- "string" mode seems to work, and considered the main mode.
- "strings" mode only works when pitch and modulation pitch are kept low, this is due to cpu constaints, if I cut it down to 4 strings it works.. but this requires an axo firmware update
- "modal" mode, this seems to be blowing up often during initialisation, and whilst I can repeat, i cannot find out precisely whats going on... its not the 'panic mode' in the resonator, ... note if it blows up, you will find other modes also stop working... when it does work, its with high pitch/mod pitch and geometry.

generally, Id recommend sticking to 'string' mode (and start the patch with it in this mode, don't switch to it from 'modal'!)

dev info
as mentioned previously we are running at 48k compared to MI 32k, and also running with smaller sample buffers, this is causing quite a few issues in lmnts, since its running out of processing power at these SR.
fundamentally, this is quite an issue... downsampling is nontrivial, and doing it, also costs cpu resources.
(it should be remembered, that Elements runs on the same processor as Axoloti, and only performs one function, so its not entirely surprising... its using 100% of it, and that Axo cannot run the same code at a much higher SR)

sorry, thats about it, Ive spent quite a bit of time on this (mostly trying to decipher MI code), and Ive not really got more to spare at this point, I may take a further look when we do another release, and it moves out of the firmware. (this will make it slightly easier to debug and test, and also change) ..
it may be perhaps exposing the 'resonator' (which appears to be the core of the issue with modal mode) may allow it to be debugged easier in isolation.

anyway, hope its useful to some
Mark

#19

Just synced my libraries, and as if by magic, the Elements objects have lots of lovely inlets!

Of course it was thetechnobear who did it, not magic, so thanks again for the work you've done on these, they add a lot of utility to Axoloti's patching environment.

Regards the processing load, it's to be expected at that bit-depth and sampling rate, I know, but I can't help feeling that one of Axoloti's biggest issues is it's locked-down bit-depth and sampling rate. Don't know if it will ever happen, but I really hope Johannes will make it user selectable in the future.

Before I started to read deeper into Axoloti, I thought wow, with all that processing power it'll be able to handle massive 8-bit projects with low sampling rates. And at the opposite end of the spectrum I thought, well, it will also be able to handle very small but super-high fidelity projects at the maximum ability of the hardware. Unfortunately we can do neither at the moment cause we can't make our own settings. Even with a drop to 16-bit 44.1KHz, the stuff that's maxing-out the Axoloti right now would have more room to breathe and make more complex stuff possible.

Anyway, that's another topic, but it's something I really hope Johannes will remedy in a future update, it would be the icing on the cake to have independent user-selectable bit-depth and sample rate!

#20

It's not as easy as making a sample rate switch in firmware: patches and objects can sound quite different at different sample rates even after adjusting the tuning of filters and oscillators, this may not seem to be a big issue, but I fear it can cause confusion when copy-pasting one object or sub-patch from one patch into another running at a different sample rate. For some objects, 96kHz sample rate could swing the balance to using different algorithms than at 48kHz.
Adjusting/scaling filters and oscillators involves quite some work.
And also, it complicates the development of the digital audio interconnect between multiple Axoloti Cores, all Cores would need to run at the same sample rate.
The technology allows it, so I understand, it feels like it should be exposed. At this point it is a substantial effort, and prefer to focus my efforts on other features. That balance can certainly change in the future.

There is no performance benefit in reducing to 16 bit I/O for the adc/dac.