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.
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 
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
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!
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.
hope you enjoy it
yeah, sample rate is very difficult, this has been discussed before, and its non-trivial - and also you want to keep the axo code optimised. (its not like a PC/Mac, where you can afford to have extra processing code)... that kind of the issue here, we dont have the spare cpu cycles to do the downsample/upsample.
@johannes - totally agree.
I wonder, if it could be an option for 'advanced development', for when your almost using axoloti as a 'bare board' perhaps even just document how it could feasibly be done.. rather than have it in the patcher UI?
e.g what changes are needed to switch? are there changes required to the firmware, and a recompile?
Im thinking a complete hack really, but it could be useful in some cases, like this, where the board is essentially only going to run one custom object....because there will be no CPU left to do anything else anyway 
(this is all probably better discussed here)
as I say, doesn't really solve the MI case here, as many might want to combine the objects with other things,
and at the end of the day, Im not trying to create a 'standalone MI elements board' - you can do this by getting a small eurorack case and an MI elements
To mutate the firmware to run at a different but fixed sample rate - I'm assuming the reader is familiar with firmware editing/compiling : this requires changing some register values in codec_ADAU1961_SAI.c The meaning of the registers can be found in the ADAU1961 datasheet. Register R17 can be set to 0x06 for 96kHz, or 0x05 for 32kHz. To change from 48kHz-derived samplerates to 44.1kHz-derived samplerates, register R2 needs to be changed. Also the computation of the dsp load in patch.c will need to be adapted.
so change the PLLC, ok, seen similar for bela... doesn't look too hard for a bare bones setup.
perhaps, we could make change the dspLoad calc, so it can be set from outside the firmware.
then this could be done without a firmware rebuild, (just need to change the kRate assumption =3000))
you can change the PLLC registers using ADAU1961_WriteRegister6(ADAU1961_REG_R1_PLLC, &pllreg[0]) in your own patch code, no need to change hw_init.
actually we could abstract the pll code, e.g a function like setPLL(int,int,int,int,int,int,int)
I suspected it might be a substantial thing to implement, but thanks for the heads-up on the situation, and at least you never said 'no' to the idea. Maybe something to consider if you do a major revision of the software or firmware. Would definitely be nice to have, especially for those of us who plan to use Axoloti boards in commercial enterprises (which I do), so that we can market our devices as having the the Bit-depth and Sampling-rate of our choosing.
I think I'm safe regards processing requirements even when using the Elements reverb, as long as I can fit my own in there along-side it. I used the Elements Reverb object as an example of needing modulation controls because I'm working on my own reverb algorithms completely through patching (I'm not a coder). The Elements reverb being so nice, I wanted to run it along with my own reverb designs in the same box, so that I can just switch between them while still being able to modulate both versions with the same modulators, both at the same time.
Anyway, thanks, I'll take a look at the thread you pointed out, and my apologies to mwvm because it's beginning to look like I hijacked his thread 
yes, its mounted, Starting patch...
sdram_get_free 8388608
Bytes Read /shared/elements/smp_sample_data.raw, 256026
Bytes Read /shared/elements/smp_noise_data.raw, 81926
Elements loading sample complete, SDRAM free 8050652
Elements initialised, SDRAM free 7923676
Done starting patch
Start locking
Done locking
but when go LIVE, - 100%
ok, lmnts is very sensitive to the parameters values, and some modes in particular
the second resonator, this is fine with most settings
the third will be fine, with low pitches
I can't remember what the first resonator had to be set too, to get it to play nicely 
(... there will be some settings, otherwise i would have disabled it.)
really you have to experiment with lmnts to find what works for you.
(there is also a help patch)
for the next release, Im also hoping to release some updated versions which might be better.
I dont know yet, I just know they work better on Organelle, so I'm hoping these changes will bring similar benefits to Axoloti... but it depends, Organelle has more CPU available, and I think lmnts is a bit cpu bound on axoloti for some resonators.
Thank You, yes, resonator I - 100%, II - 60 and III - 89% at clean project. Not try to change resonator mode before.
Unsure what Iβm doing wrong but canβt get any sound out of the lmnts patch. Any ideas? Tried with midi in object and stereo out object.
Hello !
how can i access the other modes in clds? there is only 2 options there, granular & stretch.. or do i have some old version of something ?
thanks !
I suppose the buffer size(s) can't be dynamically changed, as it's part of the init code ?
Probably changing it would make axoloti crash ?
It would be great, even BEFORE powering the axo, to specify the buffer's length (and, let's say, unable the buffer change once the patch is loaded, to avoid later crashes).
I managed to get clds to work pretty well.
The main limitation is the density that cannot go too low or high compare to what I get from its VCV equivalent but I get that could be some DSP limitation.
So first thanks a lot @thetechnobear for the port.
Just one think I don't get, what is the role of the large and small buffer?
Any recommendation on where there should be set (in the help patch they are both set to minimum 131072 and 65536)?
