crashing hell on Mac, please help!

[SWB]

Since  r1305 (I’m not really sure, but since that revision I’m using scripts for handling MIDI-in messages) I’m experiencing constant crashes on my Mac with Ctrlr (r1312). First thought was faulty scripts, but I’m only using two very simple basic scripts and verified (communicated this with the author) that they cannot be the real  cause of the crashes. After almost 100! crashes I’ve almost had it. I have reinstalled drivers for my Midi interface (Scarlett 18i6) and restarted all the involved devices millions of times, but all to no avail! I have attached (part of) the crash report, maybe some more experienced Mac user can analyze it and tell me what can be the cause. This time ANY help very much appreciated!

Attachments:

You must be logged in to view attached files.

[atom]

The crash report shows it’s a LUA issue, i can help but i need to actual panel as bpanelz file to be able to debug what’s going on, if it’s a problem with Ctrlr, Lua or the Ctrlr/Lua interaction.

[SWB]

OK, I have attached the panel.

Attachments:

You must be logged in to view attached files.

[atom]

Can you also attach some sysex data that causes the crash ? can you for example disable the Lua method and send the data that causes the crash and paste it here ? i need to somehow reproduce the problem.

[SWB]

Well, I’m not really sure what you mean by this, but the crashes appear since I analyze (and use) incoming Midi data, so I have attached a screen print of those data. I hope this is what you mean, otherwise let me know what else you need.

Attachments:

You must be logged in to view attached files.

[atom]

There is a lot that’s wrong with your code, i’ll try to point stuff out to you

1)

if mt == 7 then

use enums so other people can read your code, that’s what they’re for:

if mt == CtrlrMidiMessage.ProgramChange then

2)

chn = midi:getData():getByte(0)

Why do that ? Program Change is a defined controller and you can call getValue() on the CtrlrMidiMessage to get it’s value, don’t access the raw memory data unless you really need to

chn = midi:getValue()

3)

count = count + 1

When you start the panel, and send a program change message to your panel you get an error

Error message: [string “–…”]:12: attempt to perform arithmetic on global ‘count’ (a nil value).
Method disabled”

You are trying to add 1 to something that does not exist, you need to initialize your values to some defaults before you use them, you can’t add 1 to nothing. Those errors appear all over your code.

4)

if value==0 then
		panel:getComponent("LCD"):setComponentText(lcd_basic_text.."\r".."No Effect")
	elseif
		value==1 then
		panel:getComponent("LCD"):setComponentText(lcd_basic_text.."\r".."Room")
	elseif
		value==2 then
		panel:getComponent("LCD"):setComponentText(lcd_basic_text.."\r".."Stage")
	elseif
		value==3 then
		panel:getComponent("LCD"):setComponentText(lcd_basic_text.."\r".."Hall")
	end	

Avoid this, fetch your LCD component once and use that variable, don’t call getComponent() all the time it will cause performance issues when stuff gets more complicated.

[SWB]

Thanks for pointing all this out!

1) I just used code from other panels. Nowhere can I find information to know I  can also/have to write: ‘mt = CtrlrMidiMessage.ProgramChange’

2) I tried using getValue(), but then I’m only getting the value of the second byte (the preset number) which I already got by using getByte(1). For my purpose I need the channel information (getByte(0)) to distinguish between the presets on those channels.

3) I’m not getting any feedback on errors while using Ctrlr on Mac. So no error message  on ‘count = count + 1’ (BTW an old Visual Basic habit, won’t make that mistake again ;-)…) I need the counting because if the count is 2 (which means there are preset names received on two channels) then I need to display two preset names in the LCD panel, otherwise only one name.

4) You’re right, this can be programmed much more efficient, but not yet a concern to me at this stage.

I seems all to boil down to the problem that ANY Lua(-related) error (and in the process of learning Lua scripting I make a lot of mistakes!) on the Mac doesn’t trigger the error feedback as on Windows, but immediately crashes Ctrlr.

Thanks very much for all your help!

 

[atom]

I checked your panel on my virtual OSX and it seems to crash when it shouldn’t i need to load up the Ctrlr project and try to debug it, it might take a while since the virtual machine isn’t performing very well and any development on it is slow even with loads of resources. But keep an eye for a bugfix (if i find anything)

[atom]

This looks like an issue with the Apple LLVM compiler, i used to compile Ctrlr using GCC on the mac, but ever since Jules (the author of JUCE) started using LLVM and said a lot of good stuff about it i made Ctrlr compile with LLVM/Clang, but it looks like exceptions are not working when compiled with LLVM/Clang, so i’m doing a nightly build with GCC.

 

But (and it’s a big butt) i need to find a solution for Clang or Ctrlr won’t work on the Mac, this is what Apple is saying:

Important: The LLVM GCC compiler does not include the latest Objective-C and C++11 features. Xcode 4.6 is the last major Xcode release which includes the LLVM GCC compiler and the GDB debugger. Please migrate your projects to use the LLVM compiler and LLDB debugger, and file a bug in bugreporter.apple.com for any issues that require you to use LLVM GCC or GDB.

So i’m fucked, can’t use GCC anymore, need a solution for LLVM/Clang.

[SWB]

OK. Wish I could help, but all this is way above my head. Anyway, again many thanks for the help and all the luck with these compile issues. I personally don’t mind though developing on Windows, provided a finished panel will work on a Mac. Still need to find a way to get my Midi setup working on my windows computer . I’m using VMWare Fusion to run Win 7 on my Mac. Strange I can’t get it to work… Good night.

[SWB]

Downloaded nightly r1315 for Mac and Lua warnings for errors are back and no more frequent crashes (knock on wood…)! Great job atom, hope you did sleep well 😉 Now I can finally concentrate on writing good Lua scripts ;-)!

[Author]

Posts