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.

just downloaded the latest version and wanted to change the LCD line count but i get an error when building atom@elab /c/Users/atom/Downloads/midibox_sid_v2_040 $ gpasm.exe -v gpasm-0.13.5 beta atom@elab /c/Users/atom/Downloads/midibox_sid_v2_040 $ make rm -rf *.cod *.lst *.err rm -rf *.hex gpasm -p p18f4685 -I./src -I ./include/asm -I ./include/share -I ./modules/j5_ io -I ./modules/aout setup_6581.asm src/main.inc:25:Warning [209] Missing quote. src/main.inc:25:Error [103] syntax error ./include/asm\macros.h:188:Error [113] Symbol not previously defined (MBSID_VERS ION_STR). make: *** [setup_6581.hex] Error 1 atom@elab /c/Users/atom/Downloads/midibox_sid_v2_040 Version issues ? @update nevermind had to download the latest gputils from sf.net the WIKI link points to the 13.5 version and thus the error appears.

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.

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

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.

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

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

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

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.

yup that's the case, need to get the newer PIC i guess ?

It happens both with my and your builds on Win64, it looks weird i'll try to submit a dump of what's happening, the voltages seem fine i did the optimized C64 PSU and it seems to work and am using that for my tests.

I agree i just saw some MIDI fixes on the MAC and i know you use the MAC so it might help out later on. Also i was wondering was there ever a problem when sending large programs to the CORE, i'm able to upload a small app (lcd test, or the midi monitor hex). When uploading the SID application i get an error at about 23% always.

I thought i'll get back to my sid after over a year of doing nothing. I noticed the MIOS Studio uses the very old 1.52 version of JUCE, i thought i'd port it to the new 2.0 version and add a Introjucer project for anyone interested. The sources are attached, it's based on the latest git version of juce at the day i'm posting this. Need to get my LCD running, the core is set up, the studio hangs a lot on my ESI M8U XL on win7 64 when exiting, actually the hang happens when the device is beeing changed it does not need to be exit, it hangs never being able to close the device. I haven't looked at the Studio code itself, my Ctrlr app doing open/close never dies on the same devices and i'm using the same JUCE code so i'm guessing you might be doing something before closing the devices that causes the hang. mios_studio.7z

Not really a MIDI question but very related. The EX800 is a cheap poly synth from the 80s (keyboard-less rack mount module version of a Poly 800 synth), it has a minimal midi with only dumps and pitch-bend. The programming is done by entering a parameter number (all params are printed on the front panel) and assigning a value with a UP/DOWN value buttons. Now the question is can theese buttons be replaced with a knob, if so how. I have a Evolkver synth also that has theese endless rotary controllers that are not smooth but they "jump" a little when turning them, the whole synth (both the evolver and the korg) are digitally controlled. Are there any knobs that would fit into the Korg to make the programming better, a knob would be amazing. I have a SCI multitrack where the programming is similar, one knob and an array of params, but it works nice. So doing the same in the korg would be great. I will be looking inside the korg soon to place 3 knobs for the filter cutoff/resonance and dco->cutoff, as described in the Moog Slayer Filter mod for the EX800, so i can give any info on the parts used. Any help is very welcomed.

I use a PSU used for powering cell phones in workshops, got it new. The voltage seems pretty stable up two a hundred part of a voltage 0.0x. As for the test circuit i'll run it again today, i used the same resisotrs as on the schematic, had to go to the shop to get them but they're exactly the same. As for the placement, i'll try switching it but i have the DOT that's suppose to point eh 1st pin. Like I said theese opto's that i have are white, but i think a spec for a perticular model stays the sme no matter what manufacturer makes them (or am i wrong?). So there is no danger that the voltage that comes onto the opto is too low to drive it ?