Sanders

@enchse No, unfortunately there's no way to currently achieve that behaviour, other than resetting it to some preset yourself (with a macro snapshot for example)

@Torley,

Thanks for the support! It's truly appreciated to hear some feedback, instead of countless anonymous downloads :)

Glad you're enjoying the UI! Also really love that color, it's actually the official LCD color scheme of the default Ableton theme. I chose to stick to theme colours, so they dynamically adjust according to people's chosen Ableton theme.

It's always surprising how much time, effort and thought sinks into working out decent design decisions. The devil's truly in the details. Just look at some of the things Ableton releases as official M4L devices!

So, thanks again for the encouraging comment!

p.s.: I'll adjust the description.

@Torley,

The later updates already work a bit differently from the first version, no more left/right side controlling, it was a bit too iffy and easy to break (switching things around etc.). Now it actually works even more similarly to the Device Randomizer it turns out :p, you simply select the device you want to control.

Overall the par|randomizer seems to be more robust. The Innards of the Device Randomizer look scary! XD
Overall only big advantage of my version is that there's no limitations on parameters to randomize.
BTW, note that there are certain parameters that Ableton does not expose, so these can't be randomized! For example the wavetables in the Wavetable device are simply not accessible to M4L. Generally, the parameters that are mappable, are randomizable. Just so you know!

@offthesky I'm fairly positive this is a current limitation of the Drift device. The parameters aren't exposed to M4L yet. This should be fixed in one of the coming Ableton updates.

@Torley Fair point! I didn't know know about its existence I think, at the time of creating the device, or I felt it was too flawed, don't exactly recall. Had a look at the Device Randomizer, and it appears to be only able to randomize 16 parameters at a time, and can't randomize any of the buttons/enumerated parameters/quantized parameters (like drop-downs, selectors, etc.) as far as I can tell. Par|randomizer should function really fast with a pretty much unlimited set of parameters.

Then again, there's some functions like modulation that par|randomizer doesn't have, so depending on your use-case one or the other might serve you best.

@offthesky glad you like it! As far as I can see it does actually function on reload, but there's a bug that prevents the attached device name from being displayed on reload. I just made a fix, will update on Gumroad now.

Hi Dusty,

That's unfortunately not a very quick and easy thing to do, but I'll see what I can do!

Hi Henry,

You’d have to route the outputs of the panner to some audio channels, arm those and press record, that should do it.

Greets,
Sander

Hi!

That’s odd, never had that before. Are the parameters enabled?
Try a restart or a different liveset to see if the problem persists.

hi flp88,

For me everything is working as intended in Live 11, I haven't had any complaints before. How exactly are you trying to render? And why is your automation being overridden while you're rendering? I can try to help you out, or you can request a refund through Paypal if you like, I'll just fund it back. You can contact me directly by replying to the gumroad confirmation email.

regards,
Sander

Hi Makers61, if you'd like you can get in direct touch with me through email: sandernotenbaert@gmail.com

Hi Makers61, it's possible, it'll require a bit of re-calculation. I'll see what I can do if I have a bit of spare time.

Hi Ben,

Had another look at the internals, and seems that the m4l audio routing protocol is hardwired to route in stereo pairs. Your best bet is to simply route audio to a audio/return track with monitoring set to 'in', and pull its audio into 2 separate audio channels with a utility filtering out L or R respectively.

If you then only record the 'end' channels with the utility on them, that would allow for quick exporting after the initial set-up.

@benthegoof Fair point! I hadn't considered that, so implemented it now. Also fixed the ugly numbering a bit while I was at it. Updated to version 1.1!

Hi @Leescan

This device does not support .tun or .scl files, because it functions fundamentally differently: it assumes consistency over octaves and a 12 note divide of the octave, which many of the scales in those files do not have. If you want to build a scale that fits within the limitations of this device though, here is the logic behind the text files: numbers 1-12 are the amount of detuning of the corresponding not (from C up to B). Number 0 is the pitch bend range. optionally you can add number 13 to set wether the pitch bend output is in 7 or 14 bit resolution and nr 14 to set wether it outputs the MIDI notes too or just the pitch bend information. If you leave any number out, that setting will just remain in the current state.

That said, it should be fairly easy to create something (in Python for example) that generates files like that, but I'm not sure in which regard it will be faster then just doing it manually in the device itself. What particularly are you looking for? Perhaps a kind of database of common scales would not be a bad idea, definitely willing to look into the possibilities!

Thanks! That was the intention, and the challenge :)

Whoops, symbols don't work on the site apparently... Thanks ;)

🙏

You're welcome my friend! Credit goed to Razzkazz.