[TK.]

I’ve uploaded a new panel version for the latest Ctrlr version.

[TK.]

Could you please check if the AU plugin in Ctrlr_1209.dmg is working?

It can be downloaded from http://ctrlr.org/forums/topic/nightly-standalone/

Best Regards, Thorsten.

[TK.]

Excellent work, atom!
The build works perfectly at my side without any modifications – hurray! 🙂

If you shouldn’t find the time to release updates in future, I will help out again of course.

Unfortunately with r1263 I’ve still the same issues like with r1239: the images loaded from the MIDIbox SID .bpanelz file are not displayed anymore. :-/

Best Regards, Thorsten.

[TK.]

Depends on what are you doing… is it necessary to parse the SysEx command from a string, or would it help to define it in an array instead, such as “midi = CtrlrMidiMessage({0xf0, 0x01, 0x25, 0x05, 0x00, 0x00, 0xf7})”

This would be the faster (and preferred) method anyhow (IMHO…) – and it works with older Ctrlr versions.

Best Regards, Thorsten.

[TK.]

@Bomma72:

Hi, can someone confirm that this is working with Lion?

I can confirm that the example is still not working.
It works when the midi message is set from an array, but it doesn’t work with “midi = CtrlrMidiMessage(requestData:getText())” which could be related to a conversion issue.

@atom:

i’ll report JUCE git repository versions with svn commits

Thank you, this would really have saved some troubleshooting effort in the past! 🙂
Just write the juce git version into a file which is part of the repository, and which will be committed whenever you are doing “nightly” releases.

Best Regards, Thorsten.

[TK.]

Could you please open a separate thread for these issues, I can’t help out on general Ctrlr issues.

Best Regards, Thorsten.

[TK.]

Thank you! 🙂
Standalone Build is working without changes, but AU Build is failing with compile errors.
Which Juce version are you using locally exactly? And would it be possible to document this somewhere in the repository?
“Using the latest version” doesn’t help if somebody else tries to reconstruct Ctrlr at exactly the same state as on your side some hours, days or even weeks later (can’t repeat it often again: a baseline over all resources is required).

My MBSID panel shows the same errors as reported here: http://ctrlr.org/forums/topic/rev-1220-and-missing-resources/
When loading it from a .bpanelz file, no images are displayed…

To all Mac users: you will find links to Ctrlr_1239_Xcode3.dmg and Ctrlr_1239_Xcode4.dmg in the header of this thread.
It would be interesting, if the Xcode4 variant works under MacOS Leopard and Snow Leopard (10.5 and 10.6) – if it works, I will only provide this build in future.

Best Regards, Thorsten.

• This reply was modified 11 years, 3 months ago by TK..

[TK.]

Proposal for priorities:
1) stay at Xcode3 and VC2010, because it works at your side + stick at a boost and juce version
2) fix the reported bugs
3) work towards a stable release to ensure that existing panels are working (again)
4) release a stable version
5) create a new baseline
6) update juce and boost, adapt the Ctrlr code accordingly
7) create a new baseline
8) update to Xcode 4 and VC2012
9) create a new baseline
10) think about the next generation Ctrlr (without considering that existing panels are still compatible)

Best Regards, Thorsten.

• This reply was modified 11 years, 3 months ago by TK..

[TK.]

Addendum: according to the download stats of ucapps.de, 71 users downloaded Ctrlr_1209.exe, and 167 users downloaded Ctrlr_1209.dmg! (70%)

Best Regards, Thorsten.

• This reply was modified 11 years, 3 months ago by TK..

[TK.]

@atom: does it make sense that we are going back to an older (compatible) juce revision, and stay at this version it in the next months to avoid such dependencies with your own sources?

Background: according to the download stats ca. 40% of Ctrlr users are working on a Mac – since the release process is too cumbersome for you, I tried to help out so that this user group (including myself) is serviced with bugfixes as well, and is able to give you feedback on the latest developments.

From my point of view the Ctrlr project could really benefit from a clear baseline across all resources (not only juce, but also boost and compiler versions). I’m willing to help you out – but I need your cooperation!

Best Regards, Thorsten.

• This reply was modified 11 years, 3 months ago by TK..

[TK.]

Yes, a simplified test procedure would be sufficient. All Lua incompatibility issues that I had in the past can be reproduced by loading the panel and moving one of the oscillator or filter faders.
SysEx messages should be sent, and you should never see a Lua error message.

Best Regards, Thorsten.

 

[TK.]

It was your proposal to program the rotation stuff this way – now it’s your issue! 😉

Best Regards, Thorsten.

[TK.]

Yes, a modulator, and it still fails with r1218

I strongly recommend you to use the latest MBSID panel for testing purposes before doing any release (even nightlies): http://midibox.org/forums/topic/16709-ctrlr-based-editor-for-mbsid-v2/

to ensure that you won’t run into compatibility issues again.
Not at least I recommend it, because you own a MBSID as well, which means that you are able to test all transactions! 🙂

Best Regards, Thorsten.

• This reply was modified 11 years, 3 months ago by TK..

[TK.]

I’m happy to help out till then (and I reported an issue… ;-))

Please find the link to Ctrlr_1217.dmg in the first posting – note that due to a removed Lua function my MIDIbox SID panel doesn’t work anymore, therefore this version is not recommended for MIDIbox users.

Best Regards, Thorsten.

• This reply was modified 11 years, 3 months ago by TK..

[TK.]

mod:getX() doesn’t work anymore – is this compatibility issue really intended?
Best Regards, Thorsten.

[TK.]

No Problem!

This function is hooked into the “before any modulators are created” hook, which you can specify in the main configuration of your panel:

[code]
function init ()
console(“init”)

disableMidiMessages = true
end
[/code]

And this function is hooked into the “panel has finished loading” callback:
[code]
function postInit ()
console(“postInit”)

disableMidiMessages = false
end
[/code]

Whenever a modulator calls a Lua function, I’m writing:

[code]
sendLfo = function(modulator, newValue)

if( disableMidiMessages ) then
return
end
…
[/code]

And in the SysEx receive function, which transfers a received value to a modulator, I’m writing:
[code]
…
local prevDisableMidiMessages = disableMidiMessages
disableMidiMessages = true — global
modulator:setModulatorValue(value, notify_vst_host, notify_midi_device, notify_component)
disableMidiMessages = prevDisableMidiMessages — global
…
[/code]

Best Regards, Thorsten.

P.S.: sorry for the bad formatting – it seems that this forum can’t handle common BBCodes correctly

• This reply was modified 11 years, 3 months ago by TK..

[TK.]

In my panels I’m using a variable to disable MIDI messages.

Filtering is enabled in the hook which is called before any modulators are created, and it’s disabled in the hook which is called when the panel has finished loading.

I’m also using this mechanism from a hook which processes incoming SysEx messages – so, it was available anyhow, and didn’t result into additional overhead.

Best Regards, Thorsten.

[TK.]

Finally the MIDIbox SID V2 panel is running with the latest (and greatest) Ctrlr 1209 release under Windows and MacOS 🙂
Download links: http://midibox.org/forums/topic/16709-ctrlr-based-editor-for-mbsid-v2/

Best Regards, Thorsten.

[TK.]

🙂

[TK.]

Thanks for the report – I noticed that you are using MacOS 10.7, and I probably compiled for 10.8 only… this should be fixed now in the binary that you can find in the first posting (Ctrlr_1209_2) – it should even run under Leopard (10.5); please give it a try! 🙂

Best Regards, Thorsten.

• This reply was modified 11 years, 3 months ago by TK..

[Author]

Posts