90 replies to this topic

[TK.]

I'm waiting for the MacOS build, so that I'm finally able to integrate the patch name change function into the panel.

Best Regards, Thorsten.

[Param1]

The new build does not work at all with the new SID panel. To be honest I think the ctrl project is pretty much failsauce... it has been around quite a while and there have been many builds but it is still buggy as hell. Well, I can't complain, it's freeware afterall, I know, but Thorsten, I think you must take over the complete ctrl project, the original maker is overchallgend and I gave up on him :P OK, mean jokes aside, here is the error message I get:


Callback error: requestinit
lua runtime error

at line -1

what
c
name what:
method
Name:
setmodulatorvalue
error message:
no matching overloud found, candidates
void setmodulatorvalue(ctrlmodulator&,int,bool,bool,bool)
method disabled

----------------------

Callback error: sendens

lua runtime error

at line 43
string "..."

error message
string "...": 43: attempt to call global "sendsysexparameter16' (a nil value)

method disabled

------------------------

By the way, all of the recent versions of ctrl take ages to just load.

[atom]

It can't be that bad cause it works with other synths and other people use it. Some of the panels take a long time to load because the amount of resources people used (loads of images to paint). I'm working on that all the time but it's hard to make it load faster and use the XML scheme for panels. I'll be more then glad to help out with any problems i can just report what's not working. When it comes to LUA scripting it's hard to help out, it's the authors responsibility to make the LUA scripts fail safe. I hope you don't give up on me.

I made a nice feature that allows to export each panel as a standalone instance (standalone, vst, au) this allows the author of the panel to manage version changes as he/she wishes. Such exported instance hosts only one panel and is dedicated to it, this solves the parameter automation problems in hosts.

I'm also trying to finish my own SID and once that's done i'll try to help out with the panel for it. I know that TK uses MAC for his development i myself find the OSX hard to grasp and use Windows myself this is why the MAC builds are outdated and might contain bugs i don't see on windows.

Edited by atom, 15 June 2012 - 17:22.

[TK.]

Actually the bugs which currently prevent us from using the MBSID panel with newer Ctrlr versions exists in the Windows and Mac build.
After the Panel is loaded, a lot of "attempt to index a nil value" messages pop up.

I guess that this happens because Ctrlr tries to send MIDI events via the Lua scripts before the complete panel has been created.
The Lua scripts are trying to access components which haven't been constructed at this moment - and this leads to the failure.
This also automatically disables the scripts, and therefore most controllers don't send MIDI events anymore.

It would be helpful if controllers wouldn't be sent during panel load (or only if explicitly requested by the panel created), because this is leading to inconsistencies at my side (4 engines with different SysEx views are handled by a single panel).
It also increases the startup time (ca. 2..5 mS per parameter due to the MIDI baudrate related bottleneck)

Note that this not only causes a problem with MIDIbox synths, e.g. some older synths could fail if they are receiving too much data.

And in general it's always a good idea to construct all components first before triggering actions (the current handling could also cause issues with other panels)

I made a nice feature that allows to export each panel as a standalone instance (standalone, vst, au) this allows the author of the panel to manage version changes as he/she wishes. Such exported instance hosts only one panel and is dedicated to it, this solves the parameter automation problems in hosts.

Will it be possible to provide a standalone version with multiple panels?
I'm asking because it could be that users who are working under Windows mostly don't have a multi-client capable interface, which means that they could only use a single panel (e.g. either MBSID *or* MBFM) anymore.

Best Regards, Thorsten.

[atom]

I guess that this happens because Ctrlr tries to send MIDI events via the Lua scripts before the complete panel has been created.
The Lua scripts are trying to access components which haven't been constructed at this moment - and this leads to the failure.
This also automatically disables the scripts, and therefore most controllers don't send MIDI events anymore.

You shouldn't do anything while the panel is loading, you can check that using panel:getRestoreState() method, if that returns true the panel is
still in it's restore state and you shouldn't access other components at that point.

There are 2 special callbacks in the panel luaPanelBeforeLoad and luaPanelLoaded the first one gives you the chance to initialize any objects
or data structures before any modulators are created the other one is executed when the panel is completed and all modulators are ready.

Also always check your objects. If a method that gets a modulator returns nil then it means either the modulator does not exist, has been deleted
or is not created yet. I thought of fixing this for the users but i decided it's a bad idea (i wanted to return a invalid modulator that would
simply ignore any calls made to it, but that would cause the programmer to ignore that as an error, that's why i decided to return null poitners
or lua "nil" to force people checking the validity of their objects.

It would be helpful if controllers wouldn't be sent during panel load (or only if explicitly requested by the panel created), because this is leading to inconsistencies at my side (4 engines with different SysEx views are handled by a single panel).
It also increases the startup time (ca. 2..5 mS per parameter due to the MIDI baudrate related bottleneck)

Each modulator has a property "modulatorMuteOnStart" that should be set if you don't want the modulator to send any midi during startup. Instead set the property for the panel: panelMidiSnapshotAfterLoad and set the delay for the snapshot that's right for the device panelMidiSnapshotDelay (it will also prompt a modal dialog with a progress bar giving the user a chance
to cancel the snapshot if he/she wishes)

Will it be possible to provide a standalone version with multiple panels?
I'm asking because it could be that users who are working under Windows mostly don't have a multi-client capable interface, which means that they could only use a single panel (e.g. either MBSID *or* MBFM) anymore.

I'll be going a different direction i'll try to add support for Kernel Streaming that will overcome the problem of sharing MIDI devices on Windows, that's something i've been doing for some time now but i wanted Jules to add this to JUCE if possible, but it looks like he doesn't have the time to do that so i'll try to add this myself. But if that won't work, then yes i thought of "panel collections" that would be exported as a standalone instance, hopefuly that won't be necessary.

I'm working on the performance stuff all the time. The two biggest delays when loading a panel are MIDI messages and loading Images.

Edited by atom, 15 June 2012 - 22:50.

[TK.]

Now let's see your statements from a user point of view:

You shouldn't do anything while the panel is loading, you can check that using panel:getRestoreState() method, if that returns true the panel is
still in it's restore state and you shouldn't access other components at that point.

This requirement wasn't documented, it leads to incompatibilities with existing panels and it will result into some programming effort at the user's side - can it be avoided to make the usage as much comfortable as possible?
From my (programmers) point of view it is a design flaw if events are triggered before all objects of the "mother class" (-> the panel) have been constructed.

There are 2 special callbacks in the panel luaPanelBeforeLoad and luaPanelLoaded the first one gives you the chance to initialize any objects
or data structures before any modulators are created the other one is executed when the panel is completed and all modulators are ready.

So, after I spent a lot of time to create this panel, I should spend some additional time to workaround the way how Ctrlr handles the panel construction now.
How should this continue in future - I don't have enough time to check with each Ctrlr version if my panel is still compatible with all OS versions - wouldn't it be better to run some consistency (resp. "unit") tests before a release, even if it's only a "nightly build"?
I would be glad to provide the MBSID panel as a "unit test" ;-)

Also always check your objects. If a method that gets a modulator returns nil then it means either the modulator does not exist, has been deleted
or is not created yet. I thought of fixing this for the users but i decided it's a bad idea (i wanted to return a invalid modulator that would
simply ignore any calls made to it, but that would cause the programmer to ignore that as an error, that's why i decided to return null poitners
or lua "nil" to force people checking the validity of their objects.

From my point of view unnecessary programming effort because I assume that all objects exist before a modulator event triggers a Lua script.
I only want to be informed (via error message) if I accessed an non-existent modulator during runtime - but I don't want to consider programming details of Ctrlr during the undefined construction phase (objects could be constructed in any order...)

Sorry if this sounds a bit harsh, but I must say that I'm a bit de-illusionated after I changed from JSynthLib to Ctrlr, and now have to face new compatibility and maintenance issues that I originally wanted to see solved.
I even can't build Ctrlr by myself because of the usage of undefined library versions...

Best Regards, Thorsten.

[atom]

A lot is undocumented, i really can't say anything to this, it's just not documented and needs to be.

As for the invalid objects, it's a bad idea to assume that a get method will always return a valid object.
Lua is not a high level programming language (witch makes it fast) so you are working with pointers here
and you always need to check if they're valid, when writing Ctrlr i assumed that a modulator can be deleted/added
at runtime, and checking if a pointer is valid is up to the programmer, like i said i can add a safe way out but
i'm not sure if it's the right way out.

Panels will always be OS compatible, it's the Ctrlr version itself that might change and can cause some panels
to behave differently. But that's why i added the export instance feature to help panel creators maintain their
releases, once done with one Ctrlr version tested and working shold be distributed as an instance with that version.
Ctrlr won't update such instances (the binary under the panel). I will provide an update interface in LUA for such instance
so that designers can update Ctrlr when they decide to, not when i release a new build.

I don't know why you can't build Ctrlr, in the past 3 months i think i went over 4 installation of various OSX versions
and each time it was a matter of downloading the sources of ctrlr/juce/boost (vstsdk) to get things working in Introjucer/XCode.

What i can say is that i'm not a programmer, at least i'm not educated in that direction this is a hobby and i lack the know-how
that i see you have and others might expect. I know it's not an excuse but i can't really say anything more here. I'd like to
maintain ctrlr like you do with your projects but that takes certain practice and knowledge i don't have (unit testing, versioning etc, documentation etc.)

Edited by atom, 16 June 2012 - 01:51.

[atom]

A quick update, the new revision 1063 has a significant performance update (Ctrlr was checking for validity of each property by checking each character of the name and contents of the property looking for non-printanble special ASCII characters, this was causing a great delay when loading panels). Also you can export your panels as standalone instances on the mac and windows and distribute those instead of the panel version, if you verify your panel is working wrap it in an instance and give that to users.

I was trying your panel since i'm almost done with my MIDIBOX SID, but i'm getting some weird results, the testtone application is giving the correct 1khz sound but the normal SID app gives me noise only, i'll need to re-check the SID board and hopefully i'll be able to test out your panel. Also i was considering what you wrote about the LUA giving nil objects, i wont change that but i'll change the way the methods are called, that is they will be called only when the entire panel is loaded so all the object are accessible and indexed (the performance of the getModulatorByName() method is bad, since i need to iterate the entire modulator array to find the requested modulator) in an unchanged way throughout the life of the panel (assuming no modulator is added/removed).

[atom]

Some more updates. I got my MBSID to run. I'm using the older PIC so i had to upload the old SID program 1.73 without the CS (haven't finished that yet). But i'm guessing it should respond to MIDI events (CC/SysEx). I launched the latest ctrlr, loaded your panel and i can't get anything to work except the MIDI keyboard note on/off events. I see sysex messages going out (just in case i tested with midi yoke and midi ox). Now i qonder if the panel is for the V1 of the SID project or just V2, should the messages be compatible somehow or does the V1 use completly different MIDI data. Am i doing something wrong here ? When i power up the core i get

[20:20:51:000116]: RAW:[f0 00 00 7e 40 00 01 f7]

and that's it no output from the Core ever again. I'd like to help with that but i need a place to start. I tried the JSYnth version but tweaking anything on it causes my Windows 7 x64 to do a BSOD (i have no idea how a JAVA app can crash the system) i'm not touching that again.

[TK.]

A quick update, the new revision 1063 has a significant performance update (Ctrlr was checking for validity of each property by checking each character of the name and contents of the property looking for non-printanble special ASCII characters, this was causing a great delay when loading panels). Also you can export your panels as standalone instances on the mac and windows and distribute those instead of the panel version, if you verify your panel is working wrap it in an instance and give that to users.

I will test it once my panel is working again!

Also i was considering what you wrote about the LUA giving nil objects, i wont change that

Probably you misunderstood me, because...

but i'll change the way the methods are called, that is they will be called only when the entire panel is loaded so all the object are accessible and indexed (the performance of the getModulatorByName() method is bad, since i need to iterate the entire modulator array to find the requested modulator) in an unchanged way throughout the life of the panel (assuming no modulator is added/removed).

...this is exactly what I requested!
Also under the consideration that checking for the existence of an object costs time.
As long as the guy who created the panel has ensured, that all accessed objects exist, there is no danger.
In distance: if the guy forgot a certain object, he will be informed with an error message - all good!

It was already working this way in r946, you just changed Ctrlr into the wrong direction.

Some more updates. I got my MBSID to run. I'm using the older PIC so i had to upload the old SID program 1.73 without the CS (haven't finished that yet). But i'm guessing it should respond to MIDI events (CC/SysEx). I launched the latest ctrlr, loaded your panel and i can't get anything to work except the MIDI keyboard note on/off events. I see sysex messages going out (just in case i tested with midi yoke and midi ox). Now i qonder if the panel is for the V1 of the SID project or just V2

The panel will only work with MBSID V2, because V1 uses a different SysEx format, there are less parameters and they are structured differently.
See also the SysEx documentation in the doc/ directory of the release package (compare v1 against v2 and you will see all the differences).

Btw.: the SysEx format of MBSID V1 is similar to MBFM - so if you want to create a special panel for MBSID V1, take the MBFM panel as a starting point.

I'd like to help with that but i need a place to start. I tried the JSYnth version but tweaking anything on it causes my Windows 7 x64 to do a BSOD (i have no idea how a JAVA app can crash the system) i'm not touching that again.

Strange... are you really using this JSynthLib Snapshot 2010-12-18:
http://www.ucapps.de/jsynthlib.html

with Java 1.6 (J2SE 6.0)?

Best Regards, Thorsten.

[atom]

I used java 7 so that might be the issue, i'll try the 6th version. Also i finally found a shop that i can buy PIC18F4685 in and also the EEPROMs for the memory, so i ordered that and am awaiting shipment, i also got a 4x20 LCD so the v2 SID version is needed to get the 4 lines working.

UPDATE:
I tried Java SE 6 u23 and still a BSOD in ROMIO.sys witch is the driver file of my ESI ROMIO USB MIDI interface

Edited by atom, 03 July 2012 - 17:39.

[TK.]

UPDATE:
I tried Java SE 6 u23 and still a BSOD in ROMIO.sys witch is the driver file of my ESI ROMIO USB MIDI interface

sounds like there is a bug in the MIDI device driver.
This also explains the blue screen (which is not caused by Java itself)
It could make sense to search for an update or alternative MIDI driver.

Best Regards, Thorsten.

[atom]

I think it will be faster to buy a different MIDI cable/device, those chinese USB dongles are cheap and usually need no drivers under Win7 the generic driver works with them.

[Imp]

Don't do that! This will cause more trouble than it could possibly solve.

[TK.]

Most of those interfaces are on the blacklist: http://www.midibox.o...rface_blacklist

Especially this one which is available at Amazon for 7 EUR (since years) but doesn't output (and receive) SysEx properly:


^^^^^^^^
Don't buy!

Best Regards, Thorsten.

[atom]

Well i think i won't be using the JSynthlib stuff anyway, since i got my new PIC, burned the bootloader on it and uploaded mios and the new SID app. So Ctrlr should work with it.

[pingosimon]

Is there a way to edit multiple SID engines at once? I can select SID1 SID2 SID3 SID4 individually, but not more than one at a time.

[TK.]

Do you mean that you want to send the same parameter changes to multiple SIDs?
Currently this can't be selected in the panel, but it would be possible to add the function.

Best Regards, Thorsten.

[pingosimon]

Yeah, that's what I meant, just selecting all SIDs at once on the MB-6582 full control surface. I hope that feature is added later, as well as the ability to save/send patches!

[Bob Jumik]

Hi all, i'm new here and i bought a used sammichSID last week. I've updated it with MIOS 1.9g and MBSID v2.040.

Using Ctrlr revision 945 and MIDIbox SID v2 panel (1.7) i've been able to receive patches from the MBSID (haven't learned how to send/store them into the MBSID yet). I can control the oscillators, filters and so on thru the VSTi but the only way to make the MBSID to play from there is by pressing the play-button with the mouse. I've been trying to get it to work with Ableton Live but i cant get them to work together. There are no problems if i send MIDI from Ableton Live directly to the MBSID but if i try to do it with the VSTi nothing happens. The "Panel receives MIDI from host" doesn't seem to help either.

Has anyone got this working with Ableton Live, any help would be appreciated!

I'm using Windows 7 (64 bit)

Thanks!