mikael b's Recent Posts
Please let us know if and when we can help with alpha- and betatesting, @randy.
Unfortunately a new bout of crashes have started to reoccur at an alarming frequency in Ableton Live 10.0.x as well as in Live 10.1 betas in macOS 10.12. When I remove Aalto 1.8.5 VST from my sets there are no crashes.
See crash report example at XxXXXXX
EDIT I likely meant to post this one.
Thanks randy! I'll send to Ableton support.
Since this report then I've had a few crashes not using Aalto, also at odd moments (accessing a menu or clicking in the DAW GUI). However, crashes have decreased to a tenth or less after I've replaced Aalto in multiple sets. I could hardly do anything and a crash would occur.
Actually looking over the report again, it would appear I posted the wrong one from the clip book. I likely meant to post this one.
I'm not suggesting Aalto is directly involved in this crash either. Something else could certainly be involved. Of course, I have had Aalto on every MIDI track in every new song for quite some time so it's a natural first place to look. Starting a few days ago, no Aalto until I find the real cause.
Unfortunately, just as I and Aalto were on a such a beautiful way of discovery, I have come to the conclusion that it's the likely perpetrator of recurring crashes.
I've had a longer period of daily crashes in Live 10.0.3 and now continuing in 10.0.4 and the same is true in live 9.7.7. Usually Live goes very long periods before I see a crash and they almost never have occurred while I'm actually making music.
I have removed all other plug-ins, both VST and AU.
I have removed all Factory packs
I have disabled all MIDI ports I don't use
I have reset Live
I have installed a fresh Live 10.0.4
I have updated Aalto to the latest version
What happens is that I use Live as usual with Aalto on one track or more and some native devices. I can do just about anything to induce a crash, like stop playback with the space bar or the Push (a maximum of ten stops and bam!), move the pointer to a menu, move the pointer to the Live browser, use the arrow keys to move to the next chain in a rack, when I load a new device or plug-in from the GUI and so on.
Naturally I expect Live to not crash when I do these and whatever other actions.
What does happen is that Live crashes. Here's a recent crash report when only Aalto is active.
It seems to me — and Ableton support I think — that JuceVSTWrapper in Aalto could be involved in the cause of the crash.
Initial sessions with 1.8.4b1 indicates the insidious crashes are now history. I have encountered some odd things with my CPU dropping its frequency, but I believe this to be unrelated to our problem here and it's hopefully fixed now anyway by resetting networking (touching my wooden table).
Thanks for great work! I'm impressed.
I'll let you know if the issue reappear.
Thanks randy. I'll test this in the coming days.
Just a quick update to let you know I downgraded to version 1.8.2 and neither of the VST or AU cause these crashes now. Which is great as I don't have to replace Aalto in my projects.
Let me know if you want me to test anything.
Randy, thank you for your swift response. Oh, that's good it's something you can address.
If it doesn't take you too much time I'd be delighted to learn which rows points to what source in this case. Unfortunately I'm not familiar with C++ or Objective C, just non-GUI Java. Is it understandable one could assume JUCE components possibly being involved in this case?
I'll try again with another plug-in, but I tested the other actions I mentioned in another set with Obxd (VST) and also the native "Standard" instruments and Live was stable. But too early say anything definitive as these crashes seem to get triggered only about 1 out of 10 times or so.
Would it be possible to add value lists to parameters for the values that warrant non-contiguous values with decimals? Like for example you can't have 1.5 voices so a value with decimals makes no sense for key_voices. Yet that is what I see in Ableton Live 10.0.3.
In addition, named value lists instead of decimals would make a lot of sense for the seq_pulse# steps, like "On, Off" for toggle switches like seq_loop, key_unison, env1_xvel or env2_sustain, instead of numbers with decimals.
Likewise values like "internal, host" for seq_host, env1_trig_selec, env3_trig_selec and so on.
I'm not sure if these are lacking due to compatibility reasons, but value lists given to the host is available from other plug-in instruments that I use, so what I ask for would appear possible.
Unfortunately, while some crashes stopped, I got new ones. This one after having added Aalto AU to 2 MIDI tracks and attempting to duplicate one of them.
Crash report Aalto AU
Update: I have now switched to the AU version and there are no ridiculous crashes. I haven't done so much sessions yet, but it's looking hopeful.
It would probably be a good idea if we work together to be able to determine if it is "JuceVSTWrapper" that is behind this problem, so we can notify the developers in question or that you can adjust your usage of this code library/tool (I'm assuming here).
I'm awaiting your response, but as the AU version seems to work for now at least, please use your judgement when to address this (which is what expect). There's hopefully no hurry on my part.
And yes, Elements is a VST2 plug-in.
Could we please get an improved number scheme for the "MIDI Programs" folder?
That the user must implement a personal alphabetical scheme for using program change numbers is actually quite nuts.
For starters there's a program "0" that is selected when you send PGM 1. So to get the "1" of the presets in "MIDI Program" you must send PGM 2.
So why not use a number prefix you might ask? Sure, that would work if Aalto respected natural number ordering, which it doesn't unfortunately. So track 10 will steal slot 3 from preset "2" and shift all the other numbers upwards. So will presets with prefixes 11 and 12 and 13…
This means, unless you sort everything again in a nifty system when you send your carefully crafted program changes, you're not getting the sound you got last time. And all you did was saving a preset to the MIDI Program folder.
Why not give presets, in this folder at least, program numbers?
And why exactly is there a program "0"? Can't the offset be put into the code?
Well, thanks for contemplating improving this.
However, I must say the sound and the possibilities with this is above anything else.
Aalto is great fun to use. A little more difficult than some other synths, but there's often a reward taking those unknown paths.
For those controls that are contiguous, but also have fixed quantized positions, like for instance osc_pitch, osc_ratio and delay_freq, I suggest specific fixed positions as parameter values could make these available for the user.
As it is now you need to be very careful when getting to one of these positions so you don't over-shoot, typically ending in you have to go to the GUI anyway. Is this really necessary or is there a possible solution?
It would of course be nice if there was a standardized way to hit those fixed positions on the contiguous scale using a modifier, like a latch or key of some kind, but I'm not certain there exists such a thing.
That's why I'm suggesting to add additional quantized control parameters for those and similar controls. I've only used Aalto so far, but I suppose all Madrona synths could use something similar for their parameters.
Please consider this a suggestion. Thank you!
Yes, I want to program with my hands as I'm working the sound. I use the original Push 1, so the Push 2 adds a more graphical dimension that might be cool to explore further, though most things are via the encoders. I'm not aware of a Push 2 display API, but Ableton likes to open things up to a point so maybe there exists one.
I'd hold Aalto as one of those instruments where the users are more likely to use another type of controller. At this point I'm contemplating building my own controller for Aalto. Even though it kinda works fine from the Push.
I basically only use VST2 plug-ins, and a small number of AUs, mostly in Ableton Live 10. One of these is Waves "Elements 2.0". From this I get it all, named parameters like waveform names, rhythmic division names and On/Off, Integers and… modulation destination names!
How I would love if the Patcher was parameterized with destination names so I could control routing not via the GUI.
While you can successfully map the "seq_wave" parameter in Aalto 1.8.3 it doesn't select any of the preset patterns for the sequencer. It doesn't seem to do anything else either.
I'm mapping to one of the (original) Push encoders in Live 10.0.3 on macOS 10.12.6.
Is this parameter broken or am I misunderstanding something about this?
Good to know. Thank you!
@Uwe, This being which product? Did you mean PatchWork?
As this can be host for "VST, VST3, Audio Unit or built-in plug-ins" it would seem to fit the bill.