If you get a crash, it would be helpful if you could get a crash report. Open Console and copy and past the report into a txt file and upload here please. You shouldn’t be getting crashes and is it a one off? Or recurring?
Scaler3 Crash.txt (116.4 KB)
Thanks for your reply Davide. It’s a recurring thing. All Ableton crashes have happened in the Arrange page, when either using internal sounds or external plugins.
Thanks for that, @mrwinter1 – we’ll investigate.
Hi,
3.0.5 Version installed with clean install steps and rebooted machine, but still crashes after a few minutes. Logic Pro / Mac M1 / latest MacOs. Report attached as .txt file.
Scaler-3.05-Crash-Report.txt (57.7 KB)
Same. Windows 11. Bitwig.
Crashing regularly in Windows 11, Cakewalk (by BandLab 2024.12) on a clean install of Scaler 3.0.1 (never had 3.0 installed prior). I just saw the post about 3.0.5, so I will try that and report back.
Unfortunately no readable crash log is produced in the plugin dump folder, and no error is given, the GUI just freezes and often glitches and then straight crash to desktop.
The crashes usually occur after several minutes, but no longer than probably 15 minutes. I’ve not traced the crash to a specific action or sequence of events yet unfortunately.
The only info I can get is from Windows Event Log:
Bucket 2303883922407020584
BucketType 4
EventName APPCRASH
Response Not available
CabId 0
P1 Cakewalk.exe
P2 29.9.0.125
P3 676089bc
P4 Scaler 3.vst3
P5 1.0.3.0
P6 67e6efeb
P7 c0000005
P8 000000000061e870
P9
P10
Also note. If Scaler wants us all doing clean installs, we are going to run out of activations QUICK. Might be wise to head for another activation scheme or increase everyone to more activations now. I only have 1 left just by trying 3.0.5 to solve my crashes, and I have barely used Scaler 3! It makes little sense to even count activations on your server when the same version is installed on the same machine. I have never seen this type of activation before.
Do install 1.0.5, you should find it will resolve all issues. Does running a clean install use an activation? It shouldn’t? Just create a ticket at Support - Scaler Music and ask for some more activations.
1 Like
My activations did subtract when I ran a clean install from 3.0.1 to 3.0.5 following the instructions at the top of the thread. I will contact support as advised. Thanks for your hard work on the updates!
1 Like
Scaler 3 v1.0.5 instantly crashes Ableton the moment it’s added to a project so now I can’t even use it.
v.1.0.1 could at least get beyond this initial stage.
I’m sorry but this has the to the absolute worst release of any plugin that I’ve ever owned, no exaduration whatsoever.
It’s completely riddled with problems and it feels as though we are all still stuck in the beta testing phase. So much for all the hype.
That’s not the expected behaviour, nor is it the behaviour of thousands of users (including our entire team, network and beta team) that use it daily. There is something in your setup. Have you restarted after installing and have you tried a clean install? No need for exadurations!
Instructions for a clean Install:
Mac - Clean Install:
- Delete the standalone state file in this folder: /Users/[NAME]/Library/Application Support/Scaler 3.settings
- Delete the personalised files in this folder: /Users/[NAME]/Library/Scaler Music/Scaler 3
- Delete the shared user files in this folder: /Users/Shared/Scaler Music/Scaler 3
- Reinstall.
PC - Clean Install:
- Delete the standalone state file in this folder: C:\Users[NAME]\AppData\RoamingScaler 3.settings
- Delete the personalised files in this folder: C:\ProgramData\Scaler Music\Scaler 3
- Delete the shared user files in this folder: C:\Users\Public\Documents\Scaler Music\Scaler 3
- Reinstall.
Users may also remove the actual plugin binary files for VST/VST3/AU/AAX. However if you reinstall with your DAWs closed, these should be overwritten when reinstalling.
Haha If only.
Well I performed a clean install again and the good news is that this time around it at least seems to have nipped this specific problem in the bud after I restarted so at least that’s one less thing on my mind now, so thankyou.
Here’s just hoping that this process of manually searching down and deleting folders isn’t going to become a regular occurance with each new update.
Good news, tentatively. I have been able to work for over an hour without a crash for the first time. This is longer than the last 3 sessions where Scaler crashed on 3.0.1. I am cautiously optimistic that 3.0.5 has made things more stable in Cakewalk BL / Sonar.
I will try to give the arranger tab a good shakedown and run a few more sessions and hopefully this will stay the same.
Thanks again for your efforts.
good point thanks il check that out
I am still seeing segfaults on v1.0.5 after a clean install on macOS 15.3.2.
Most of the crashes I’ve been experiencing on this and prior versions seem related to undo/redo handling. Here is the latest one on v1.0.5:
Crashed Thread: 0 JUCE Message Thread Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000b5d7bf58
Exception Codes: 0x0000000000000001, 0x00000000b5d7bf58
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [73101]
VM Region Info: 0xb5d7bf58 is not in any region. Bytes before following region: 1286308008
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 102834000-103af8000 [ 18.8M] r-x/r-x SM=COW /Applications/Scaler 3.app/Contents/MacOS/Scaler 3
Thread 0 Crashed:: JUCE Message Thread Dispatch queue: com.apple.main-thread
0 Scaler 3 0x102b5ec80 std::__1::__hash_const_iterator<std::__1::__hash_node<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, void*>*> std::__1::__hash_table<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, Scaler::Sequencer::Properties::string_hash, std::__1::equal_to<void>, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, std::__1::equal_to<void>, Scaler::Sequencer::Properties::string_hash, true>, std::__1::allocator<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>>>::find<std::__1::basic_string_view<char, std::__1::char_traits<char>>>(std::__1::basic_string_view<char, std::__1::char_traits<char>> const&) const + 120
1 Scaler 3 0x102f7cd74 Scaler::Sequencer::Properties::has(std::__1::basic_string_view<char, std::__1::char_traits<char>>) const + 28
2 Scaler 3 0x102f77afc Scaler::Sequencer::Properties::_set(Scaler::Sequencer::ActionContext const&, std::__1::basic_string_view<char, std::__1::char_traits<char>>, std::__1::any const&) + 172
3 Scaler 3 0x102f77a44 Scaler::Sequencer::PropertiesSetAction::perform() + 32
4 Scaler 3 0x102980b90 juce::UndoManager::redo() + 108
5 Scaler 3 0x102e8b69c non-virtual thunk to Scaler::Plugin::PluginEditor::keyPressed(juce::KeyPress const&, juce::Component*) + 104
6 Scaler 3 0x102a71da0 juce::ComponentPeer::handleKeyPress(juce::KeyPress const&) + 216
7 Scaler 3 0x102a7d078 juce::NSViewComponentPeer::handleKeyEvent(NSEvent*, bool) + 256
8 Scaler 3 0x102a7cb40 juce::NSViewComponentPeer::redirectKeyDown(NSEvent*) + 76
9 Scaler 3 0x102a7c7cc juce::NSViewComponentPeer::sendEventToInputContextOrComponent(NSEvent*) + 560
10 Scaler 3 0x102a7d4a0 juce::JuceNSViewClass::JuceNSViewClass()::'lambda8'(objc_object*, objc_selector*, NSEvent*)::operator()(objc_object*, objc_selector*, NSEvent*) const + 100
11 Scaler 3 0x102a7d5e0 juce::JuceNSViewClass::JuceNSViewClass()::'lambda8'(objc_object*, objc_selector*, NSEvent*)::__invoke(objc_object*, objc_selector*, NSEvent*) + 32
12 AppKit 0x186c31f20 -[NSView performKeyEquivalent:] + 140
13 AppKit 0x1874c7870 -[NSWindow _commonPerformKeyEquivalent:conditionally:] + 68
14 AppKit 0x1873316a4 routeKeyEquivalent + 224
15 AppKit 0x18732f618 -[NSApplication(NSEventRouting) sendEvent:] + 648
16 AppKit 0x186f36b04 -[NSApplication _handleEvent:] + 60
17 AppKit 0x1869bd89c -[NSApplication run] + 520
18 Scaler 3 0x10298a86c juce::JUCEApplicationBase::main() + 192
19 Scaler 3 0x10298a78c juce::JUCEApplicationBase::main(int, char const**) + 88
20 dyld 0x1829ec274 start + 2840
This is while running standalone Scaler 3 using only the built-in instruments. Doing some series of undos and then redos often triggers a crash. Most of the crash reports have juce::UndoManager::redo() or undo() in the call stack. Here’s an example of an undo crash on v1.0.3 (just the top 4 frames to keep it shorter):
Thread 0 Crashed:: JUCE Message Thread Dispatch queue: com.apple.main-thread
0 Scaler 3 0x100eabba0 std::__1::__hash_iterator<std::__1::__hash_node<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, void*>*> std::__1::__hash_table<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, Scaler::Sequencer::Properties::string_hash, std::__1::equal_to<void>, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>, std::__1::equal_to<void>, Scaler::Sequencer::Properties::string_hash, true>, std::__1::allocator<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::any>>>::find<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) + 164
1 Scaler 3 0x100ea969c Scaler::Sequencer::Properties::_remove(Scaler::Sequencer::ActionContext const&, std::__1::basic_string_view<char, std::__1::char_traits<char>>) + 140
2 Scaler 3 0x100ea4020 Scaler::Sequencer::PropertiesSetAction::undo() + 72
3 Scaler 3 0x1008adcc4 juce::UndoManager::undo() + 116
I still haven’t succeeded at going more than 15-20 minutes on any version without experiencing a crash.
After a few more Scaler 3 session attempts I got back into the immediate crash at startup of standalone Scaler 3 that I and others were seeing on earlier versions, so this is still not fixed on v1.0.5. This happens when deserializing the state of the session that was saved at the previous closing of the app and persists until the /Users/[NAME]/Library/Application Support/Scaler 3.settings file is deleted.
Call stack of the offending thread:
Crashed Thread: 0 JUCE Message Thread Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: Scaler 3 [78964]
Application Specific Information:
abort() called
Thread 0 Crashed:: JUCE Message Thread Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x182d33720 __pthread_kill + 8
1 libsystem_pthread.dylib 0x182d6bf70 pthread_kill + 288
2 libsystem_c.dylib 0x182c78908 abort + 128
3 libc++abi.dylib 0x182d2244c abort_message + 132
4 libc++abi.dylib 0x182d10a24 demangling_terminate_handler() + 320
5 libobjc.A.dylib 0x1829b93f4 _objc_terminate() + 172
6 libc++abi.dylib 0x182d21710 std::__terminate(void (*)()) + 16
7 libc++abi.dylib 0x182d216b4 std::terminate() + 108
8 Scaler 3 0x104691d20 Scaler::Plugin::PluginAudioProcessor::deserialize(juce::MemoryBlock const&) + 420
9 Scaler 3 0x10418fbcc juce::MessageQueue::runLoopCallback() + 352
10 CoreFoundation 0x182e548a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
11 CoreFoundation 0x182e54838 __CFRunLoopDoSource0 + 176
12 CoreFoundation 0x182e5459c __CFRunLoopDoSources0 + 244
13 CoreFoundation 0x182e53138 __CFRunLoopRun + 840
14 CoreFoundation 0x182e52734 CFRunLoopRunSpecific + 588
15 HIToolbox 0x18e3c1530 RunCurrentEventLoopInMode + 292
16 HIToolbox 0x18e3c7348 ReceiveNextEventCommon + 676
17 HIToolbox 0x18e3c7508 _BlockUntilNextEventMatchingListInModeWithFilter + 76
18 AppKit 0x1869ca848 _DPSNextEvent + 660
19 AppKit 0x187330c24 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
20 AppKit 0x1869bd874 -[NSApplication run] + 480
21 Scaler 3 0x10418a86c juce::JUCEApplicationBase::main() + 192
22 Scaler 3 0x10418a78c juce::JUCEApplicationBase::main(int, char const**) + 88
23 dyld 0x1829ec274 start + 2840
It is a little bit better now…
I send my crash report via email because it is too long. I did a complete reinstall. Davide send the information. It still crash after ca. 40 sec. Of chords.
Has anyone here had Scaler 3 standalone crash before it opens. I have tried numerous reinstalls, turning off my Apollo Duo interface, and things I don’t remember at the moment. Nothing at all has worked. It crashes at start up and that’s it. The program runs in Studio One 7 but runs clunky there too. Anyone with the same or similar experience?
I’ve gotten into this instant crash on startup state numerous times. So far I’ve always been able to fix it by deleting Scaler’s settings file as Davide describes here.
Hi,
I have tried to delete that file as well, but there is no file to delete.