Jump to content

Ctrlr based editor for MBSID V2


TK.
 Share

Recommended Posts

R945 fixes the issues I mentioned earlier. However, one important issue remains: I can't send the patches to my Sammichs.

The Midi configuration should be OK. I can receive patches and send out knob changes. But when I load a panel into the Ctrl frame, the panel data, or the patch, does not get send to the Sammich.

Something does get send tho, as I can see the (correct) light of the correct channel blinking of my multichannel midi interface. I also tried the "send panel" button but it does not do anything.

A window pops up, stating that it's "sending messages" but it does not do so. No light emitting, nothing.

Overall the Ctrl Frame seems very buggy to me. Lots of smaller problems all over the place. But this could basically be a very cool software!

Link to comment
Share on other sites

R945 fixes the issues I mentioned earlier. However, one important issue remains: I can't send the patches to my Sammichs.

The Midi configuration should be OK. I can receive patches and send out knob changes. But when I load a panel into the Ctrl frame, the panel data, or the patch, does not get send to the Sammich.

Something does get send tho, as I can see the (correct) light of the correct channel blinking of my multichannel midi interface. I also tried the "send panel" button but it does not do anything.

A window pops up, stating that it's "sending messages" but it does not do so. No light emitting, nothing.

Currently the patch and snapshot handling will be overworked, see also: http://www.ctrlr.org/viewtopic.php?f=2&t=861 (please note: r965 fails to handle the MBSID panel correctly, please wait for a newer release, and wait until the MBSID panel supports the new features!)

Due to the upcoming conceptional changes, I haven't prepared patch sending yet - it will work flawlessly sooner or later! :)

Best Regards, Thorsten.

Link to comment
Share on other sites

Hmm, things are a bit better for me in r945 but still not great. For instance, in the lead engine only right OSCs 1-3 and left OSC 3 controls work. Left OSC 1 and 2 controls are all unresponsive. Neither channel filter section knobs are working either. Another example, in the drum engine the controls only work for D5-D10. Similar thing in the bassline engine; filter controls don't work, etc. I'm using a sammichSID with the latest firmware. The java based editor works flawlessly.

Link to comment
Share on other sites

Thank you! The MIDI log was very helpful as it shows, that you are using the Stereo Link (WOPT=1) and changed the right OSC3.

The SysEx address should point to the left OSC1 in this case, but it pointed to the right OSC1, therefore the left OSC1 wasn't updated by sammichSID (although it was updated on the panel).

Both OSCs were updated correctly when the left OSC1 was changed - and this is what I'm usually doing, therefore I haven't noticed this.

Same issue was with the filter parameters for all engines.

This is now fixed in V1.3, which can be downloaded from the DDB

I wasn't able to reproduce the drum instrument issue, could you please give more details how to reproduce it?

Best Regards, Thorsten.

Link to comment
Share on other sites

I get no effect when either the left or right OSC1 is changed, even with the new panel, so I think it's a different issue. Filter controls still don't work, either. Could it maybe be my MIDI interface?

As for the drum instrument, if I get a sequence going and try to change the drum sounds, only the knobs for D5 to D10 have any effect.

Edited by skweeegor
Link to comment
Share on other sites

Could you please create another snapshot so that I can doublecheck the output?

Please also check that you are using the new panel: right-click on panel, select edit mode -> at the right side you will see the major (1) and minor (3) version number.

MIDI Interface: of course, you have to select you own IN/OUT ports again whenever you've updated the panel.

Best Regards, Thorsten.

Link to comment
Share on other sites

I verified the version and it is 1.3.

Here's another couple of logs. The first one is with Link Stereo mode ON, and the second one is with Link Stereo mode OFF.

1st snapshot:

(Lead instrument)

Stereo link ON

1. Adjusted OSC 1 Left transpose knob (no effect)

2. Toggled OSC 1 Saw wave on and off (no effect)

3. Adjusted OSC 1 Right transpose (no effect)

4. Adjusted OSC 2 left transpose (no effect)

5. Adjusted OSC 2 right tranpose (no effect)

6. Toggled OSC 3 Left saw (works)

7. Adjusted OSC 3 Left tranpose (works)

8. Adjusted OSC 3 Right tranpose (works)

2nd snapshot:

(Lead instrument)

Stereo link OFF

1. Adjusted OSC 1 Left transpose knob (no effect)

2. Toggled OSC 1 Saw wave on and off (no effect)

3. Adjusted OSC 1 Right transpose (works)

4. Toggled OSC 2 Left saw ON (no effect)

5. Toggled OSC 2 Right saw ON (works)

6. Adjusted OSC 2 left transpose (no effect)

7. Adjusted OSC 2 right tranpose (works)

8. Toggled OSC 3 Left saw (works)

9. Adjusted OSC 3 Left tranpose (works)

10. Adjusted OSC 3 Right tranpose (no effect)

So as you can see it's pretty random what works and what doesn't, and it varies between the stereo link mode on and off.

post-7127-0-75603800-1334451240_thumb.jp

post-7127-0-58646200-1334451266_thumb.jp

Link to comment
Share on other sites

I checked this under Windows and noticed an incompatibility in the float->integer conversion which caused the wrong SysEx command.

A workaround has been added to v1.4 - please try this version.

Best Regards, Thorsten.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

  • 2 weeks later...

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...