Jump to content

normen

Members
  • Posts

    32
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by normen

  1. Hey. Sorry but I didn't extend this further yet. I do use it at times and funnily I just thought about finishing it the other day but I guess it will still take some time until I can allocate time to it again. However I did put many comments in the code and the basic UI layout is set so everybody is very welcome to extend it further. Most of the "hard" coding work and logic layout is done and new device panels can basically be copy&pasted from the existing ones, adding the UI elements and changing the code respectively. Should not be too hard really. If somebody gets around to extend it just send me a mail with the Lemur file and I will upload it for everybody else and if needed finish it when I have time again.
  2. So, I haven't completely added all new features I wanted yet and some are still half-implemented. Ensemble send isn't done yet, so it cannot be configured, but the Ensemble settings can now be loaded and viewed via the button top right. I thought some might appreciate a small update nonetheless, also as a small sign of life so nobody thinks this won't be finished ;) I have added copy/paste for whole presets and added a way to send data in addition to the ensemble settings. Also the sequencer doesn't trigger a reload anymore so you can switch between patterns quickly. The local data is stored as well when it is sent to the MidiBox so it knows about the current settings of the midibox (not just the last dump). This caused some data corruption akin to the MidiSysEx send corruption that happened sometimes, mostly because of non-truncated data being converted to bytes. I fixed most of this but if you could test this by re-applying the local data to the faders (via the info window "i" button) every now and then I'd appreciate it :) Also, if somebody with a iPad 1 cares to test if 50 SysEx messages per frame work there as well that'd be cool, I wasn't quite sure but I didn't want the uploads to take too long (they already are slower than normal due to the separate sysex messages). Also theres been some severe code cleanups :) I updated the main post and file on DropBox. Cheers, Normen
  3. Just a short update so you don't think I've forgotten about this ;) I already implemented the changes for the latest MidiBox SID version when TK posted the update (see updated post above) but atm I don't have time to work on it further. In a few days I should have time again and I'll completely clean up the code first and then add some pages and panels I definitely still want for myself like the ensemble settings etc. Then I'll make it available in a more appropriate way than dropbox and write up some docs, e.g. on googlecode or so. Edit: One issue I still have to solve is changing complete patches and/or copy-pasting patches. I can't even store an array as big as the preset arrays in the Ctrlr interface, let alone send a SysEx message that long (its an array) :( Edit: d'oh, I guess I can just send single parameter commands.. Lets hope that many in succession won't confuse Lemur.. But I am getting good at workarounds for Lemur ;)
  4. @All: Thanks, I'll update the file in dropbox every now and then, when theres big changes I'll post here. @Antix: Yes, iOS. I guess you should regard it the "windows of the post-PC-era" in terms of market leader. Makes much more sense to have the closed but proper and working system as reference and the open systems as options anyway ;) @TK: Cool, you will make the best tester I can get :) Also @TK, some questions to work on issues I have: - Can I save the current SID memory to a bank directly or do I have to send a complete dump? I guess I'd have to send it as single PolyPressure messages then too but I didn't try that yet, maybe Lemur manages to sink the whole buffer in the iPads MIDI stack.. - I have problems calculating the checkSum, it happens in PatchDump.receivePoly(MIDI_ARGS), maybe you can take a look. It outputs the various tries in the debug window accessible with the "I" button on top. - Unrelated: Can the SID *output* a MIDI Sync signal somehow? Cheers, Normen
  5. Hey folks, as indicated in I started working on a patch for Lemur to edit my MidiBox SID v2. Few panels are working yet, the main work went into working around some serious limitations in Lemur, like a max size of 255 for arrays, max sizes for execution time, stack size and general method size and other niceties. As the Lemur is incapable of receiving big SysEx dumps, you need to have at least MidiBox SID V2.042 installed. Currently working panels: - Lead Oscillator + Filter - Bass Oscillator + Filter - Bass Sequencer - Bass LFO/ENV (ENV doesn't send data yet) - Knob assignment Known Issues / TODO - Implement all functions :smile: - Selecting an engine doesn't change the engine yet, you have to load a patch with that engine - Storing patches does not work (Is there no way to store memory->bank directly? I have to send a whole dump to store??) - Sequencer editing currently causes a dump and thus dropouts when switching the edited sequence due to workaround - Sequencer copy/paste/nudge doesn't work yet - Sequencer octave labels are wrong on all but one button row :smile: I intend to do it like its written on most but that requires some more work - When linking, values that change due to inertia are not synched due to a workaround - Possibly could optimize data sent and send less parameters at once (e.g. left filter params are always sent at once) - Fail to create proper checksum atm.. Sooo.. Currently some of the code is a bit messy still but its already becoming cleaner so it should be easy to extend, I'll write up some more documentation in addition to the existing code comments and README in the project. As the editor isn't really an IDE or code editor at all some things might not be obvious directly. As I guess it'll take me a lot of time until I really add all of the panels I don't use etc, maybe somebody wants to extend this further on his own when I added all I need ;) Download link to the current version Let me know if you have some issues with the current functions or see any strangeness. Especially look out for "entangled" parameters that cause changes in each other by reloading the memory after changing a setting (use the "apply local values to faders" button in the info panel for that). This is because I don't always math.floor() the bytes I send (imagine me with a beer in my hand) to save resources and sometimes I forgot values that can actually leak. Cheers, Normen
  6. Works exactly as advertised :) Would be great to have this in by default with its own dump command. Watch out for some post-christmas presents ;)
  7. Smart :D I actually meant just sending the single addresses of the patch, not really single parameters. Thanks a lot, I guess I should be able to hobble this together like this. Cheers, Normen
  8. It turns out to complete this I'll probably need some help. I can edit parameters fine but getting patch data turns out to be impossible. The Lemur flat out drops midi messages when they take too long until the final 0xF7... This means a patch dump always takes too long and gets truncated to 10-26 bytes :( I wrote a message to them and posted in their forum but I doubt we can hope for a quick fix. So I thought of the next best fix: Would it be possible to have the MidiBox SID send its patch data as separate sysex messages, one per parameter? As a separate dump mode? I guess it should be but as I am not very proficient in assembler (I prefer the MidiBox C api ;)) it would take me very long to get this working, so I am reaching out for help on this. Cheers, Normen
  9. Cool, I'm using your Ctrlr surface as a guideline (sorry for the frustration on that side) the code for that being LUA already helps a lot :) I'll try and comment and document it best as possible so it can be extended easily. I know I will miss some functions and probably leave out some panels I seldom use on the first release. Cheers, Normen
  10. I started work on a control surface for Lemur. As I currently have most fun with the Bassline module I started doing an UI for that but its written so that it can be extended to the whole SID. The panels will adapt automatically based on the engine used and you can select one SID and basically directly work on its patches. From what I read here I guess TK also looked into doing this but theres a few things to overcome. First of all the single scripts can only have like 40 lines or so, then lists can only take 33 items (because they cannot be scrolled anyway), finally the LUA interpreter bails when the stack gets too big. This made it a bit hard to display the values for 255 parameters :) But I managed to by chaining multiple methods that each have a portion of the list, effectively I now have 12 methods and the first one looks like this (No worries, I let other code write the code for these methods :D): if(param>=231){return getParameterName11(param);} else if(param>=126){return getParameterName6(param);} else if(param == 0){return '0 | --- None ---';} else if(param == 1){return '1 | Volume';} ..... else if(param == 20){return '20 | Ext5 Value';} else return getParameterName1(param); Then the parameter selection works with a knob for coarse selection and two small buttons for the fine selection (see below). So, I hope I can get this to a workable state during the rest of this year ;) Then I'll make it available to the MIOS community to tear apart, extend, beautify and complain about ;) Bassline Oscillators Bassline Step Sequencer Knob Assignment Cheers, Normen
  11. Found a solution, albeit a rather funny one.. I set the first box to MIDI_MERGER_MBLINK_FP and the second to MIDI_MERGER_ENABLED (instead of MIDI_MERGER_MBLINK_EP!) and that seems to work when chaining the two boxes :D I can use MIOS Studio as well as Ctrlr to edit patches on both boxes via the ID now and I get only the boxes' MIDI back, no SYSEX echo.. MIOS is still confused when trying to contact the core. When I set up FP/EP the cores crash directly on restart :-?
  12. I kind of planned that space to later add a transformer, lets see. For now I'll just use two USB-MIDI cables.
  13. Hm true, did people test if the MIDI voltage can sustain this thing? I mean else I'd need another external power box or I'd have to add another connector to one of the sids which totally wrecks my layout (and probably won't fit..) :( Also didn't have too much success with MIDI merge. It works in general but e.g. the Ctrlr-surface can't receive the data from box one.. Almost seems like box two drops the data with the wrong device id or something, idk..
  14. D'oh.. I enabled midi merging and now I can't upload code anymore cause MIOS studio gets confused due to its own echo.. Guess I'll have to use some external tool if I want to change something in the future ;)
  15. Gha, no thanks :D Also its built in, so no need to go down to purse-keepable size ;) Btw, any good way to enable midi thru without adding a new port :?
  16. aaaand #2 is done too, a bit cleaner than #1 :D Btw for the BankStick I found that its very practical to put them onto development boards to connect them, I guess I'm not the first though ;)
  17. Thanks. Yep, I also thought about fitting a board exactly for this but I found that having the base boards always turns out as an advantage in the end (or after some years ;)). Do you know of any standard way to make the default PCBs fit in this case? Like an extension of the PCB somehow? When I tried using two aluminium bars in the grooves to put the upper board on those it was exactly *not* fitting, like either 2mm into the boards below or into the case top ;)
  18. Hey, After having built a 19" plugin remote control and reviving a control surface with a MIOS heart transplant I finally got around doing my first MIDIBox SID v2 synth :D I have the parts for two stereo synths based on the 8580, one is finished now and its just marvelous. I'm all back to my childhood sitting in front of my Amiga.. But its like its grown up along with me ;) First signs of life: I used the normal boards from Mike plus one Pic8 core, so basically the minimal stereo/two channel solution. I want it to be as simple and modular as possible and rather have more of these boxes than one synth with multiple chips, I already know I will build another two boxes with the 6581 too ;) The simple feature set is MIDI in and out, stereo audio out and one integrated BankStick chip for 128 presets. As I chose a quite small box for it, I have to stack the boards and I actually stick the second board on the PIC and SID of the other boards.. Ran it for a night and theres apparently no heat issue with that and it fits perfectly. Board sandwich: Fitting it in: The simple aluminium box makes it easy to drill the holes for the connections, I already have plans to add a very small 2x16 display and a rotary knob plus four small buttons to the front panel, according to my measuring that should just about work out. Maybe it will be only an LCD display though, its easy to underestimate the space needed for knobs.. And I couldn't find a 4-button sticky buttons panel.. Anyway it looks very pretty as is already :D Final Box: Idea for front panel: Thanks again TK, I already funded another beer for you, your work keeps giving me moments of bliss ;)
  19. Sooo.. The fader PCBs are there and I connected the faders of the test box and it WORKS :) Now I only gotta clean up the I/O PCB. Not sure if I'll pursue the "stick on" board thing though, might be the DINX and DOUTX boards are best placed separately. P.S.: I almost got a broken FW-1884 on eBay. I know the guy who sniped it away is reading this thread, I shall withhold the software and special wiring info ;P
  20. So.. after spreading the single purchases over a few months I now started to build a PIC Core and DINX/DOUTX module and ripped apart one FE-8. I finally decided to desolder the faders and use MF_NG boards (which are still on their way, parts are there). Without the main board and the fader board theres a lot of space in the FE-8 :) This is the circuitry on the board above, basically a button and a LED matrix, the LED matrix has some inverting transistors on the columns that make it unnecessary to keep high voltage on the inactive rows. For the application, I was poking the assembler code for the LC and the button matrix with a stick for some weeks but as getting to a state where I would be able to fluently read and write assembler code would take a month or so I decided to do the button and LED matrix in C. I also got the PIC with the largest program memory, guess that will be handy as a C-based programmer ;) The MIOS C API really is nice, I never worked with it before, only hacked around in assembler projects. So then it only took me some hours after I had the general workings of the FE-8 matrix worked out. The DINX module is driven +5V=on and the matrix works basically the other way round as the matrix in the MIOS blm examples. Modified the DINX module to support that and created a board where I can plug the DINX and DOUTX module onto female pin connectors. Since the pin rows of the DINX are "blocked" by the resistors I simply pushed the pin rows through to the bottom and soldered them there. Now I can attach the two boards to the main board and replace/reuse them if needed. The purpose of this is to connect the modules to the 17-pin connector for the FE-8 matrix (the cable mess is below, I will probably etch a PCB for that when this prototype is working) What shall I say.. It works! :D Basically I just keep bitmasks of the registers for each row that is checked (the 8 rows are cycled in my case, theres up to 16 columns in the main unit) and in the Tick method I check which ones changed and send MIDI events accordingly. Works nicely w/o debouncing as it seems, even the encoders. So now its only about getting the encoder values converted properly which I'll probably do in the tick method based on the note id thats currently reported. If anyone has a better idea (or existing code) for the encoder matrix (which is displayed in the pic above) hit me :D Expect some more frequent updates from now on ;) Thanks again TK for making all this possible. Cheers, Normen
  21. Yeah, for the main unit I'll also need two motorfader boards (I think?) as it sports a master fader in addition to the other 8 faders. The layout of the boards (FE-8 vs FW-1884) is very very similar though, the master fader is basically its own small circuit and the rest of the board is 1:1 the same as the one of the FE-8 (of which I have opened one to get further insight / start measuring and experimenting). I was thinking about using the new MIOS core for the main unit especially as now I also plan to integrate an audio board, I suppose the headroom and connectivity of the new platform will provide useful one way or the other. For now I planned one PIC Core with a few DINX and DOUTX (some buttons are laid out as matrices, still gotta check how exactly I use that with the LC emulation) and one MF_NG module per device (or two for the master), then a GM-5 USB midi in the main unit. As I said, the 4 additional MIDI in/outs with optocouplers are already in the main unit. This way I could connect the two FE-8 via MIDI to the main unit instead of FireWire (using the original MIDI connectors on the main unit) and go to the PC via the GM5 USB port. The Audio part would be a completely separate USB port, allowing to use the units audio and midi part with different computers even (which will be handy in my project studio).
  22. Thank you very much for the answer! As I'll probably aim at simulating the Tascam Protocol as opposed to the Mackie Control Protocol I am already down to creating a separate application.. I guess I'll have to put some work into understanding the MF_NG module but from what you say I take it this would require the whole MIOS base to be adapted? Or are you talking about "normal" AIN AOUT modules here? I don't even know how similar (or different) the shift registers used by MIOS and the AD on this board work.. (why the heck do they convert the touch signals there already?) I still think a drop-in replacement board would be very interesting as Tascam stopped support for this product and a similar one (US-2400) and I guess these will make great MidiBoxes when they pop up on ebay.. Maybe the app could even support the calibration protocol of the MIOS Studio MF_NG app. But as said, I am a noob in this respect and have to research a lot when I'm doing this kind of stuff so if you just told me "forget about it, makes no sense to think about it" in a nice way then I guess I'll have to live with that :) Update on the USB Audio mod The microphone and Line input circuitry with phantom power etc is in a separate block at the back of the device like I said before. Though now I saw that most of the analog preamp circuitry before the A/D is indeed on the main board of the Tascam FW1884 which I intend to remove from the device. This means I'll have to design a board with that input circuitry which gives me a chance to improve a bit on the used NJM4580 Op-Amps (maybe I'll use some OPA2604s). Luckily analog audio circuitry is something I don't have too much problems with ;) Cheers, Normen
  23. As a small update to the thread (I'll post everything about this endeavor here), I found out that Ploytec (the comany that does the GM5 midi chip) also does a USB 2.0 Audio board that should allow me to revive the audio part of the Tascam FW1884 interface as well! Its a 16in/8out USB audio interface and the analog input section of the Tascam is just about the ideal companion to this board. As with everything in the FW-1884 the analog input and output sections are nicely separated and deliver exactly what this board needs via a ribbon cable. This should allow me to just throw in this board and have a full 8 mic-pre 8 line-out interface (maybe I can even make the ADAT part work some time). On a sidenote, the GM5 midi evaluation board from ploytec is also just about ideal for the FW1884 as the GM5 needs optocouplers and midi ports for the additional 4 ports that are not on the board. Guess what, the FW1884 has 4 midi inputs and outputs and the board contains all necessary optocouplers and circuitry so I again only have to take a ribbon cable and connect it. :D Sometimes the world can be so nice, I am getting suspicious here ;) Cheers, Normen
  24. Hi, I have a Tascam FW 1884 DAW Controller with two FE-8 Extenders for which there is no driver support anymore (the device uses FireWire). As I mainly use the control surface I want to build a MidiBox core into it to continue using it. I have built a MidiBox remote before and just love the platform. First I thought about using the new Motorfader core and a PIC Core per 8 faders but when looking into the boxes the PCB's are so nicely accessible and separately wired I thought it might be possible to reuse the motorfader circuitry. Luckily I have the service manual and layout of the device but sadly I'm not very savvy in these things.. I found out theres some 10bit A/D's working on the PCB, maybe theres a way to make a MIOS PIC talk to that? Or maybe with the new platform? Here is some screenshots of the layout, it also contains the IC numbers, I wouldn't want to upload the whole service manual but tell me if you need to see other areas to tell me more. This should be the touch and input stage I guess And this is the motor driver chip it seems There is not much more on the fader PCB so this is the data bus / PWM signal the PIC would have to work with.. If it can? I'd be happy about any hints, maybe I don't have to rip out the whole fader PCB (to which the faders are soldered :/ ) then it would be a totally clean heart transplant so to speak. Cheers and keep on MidiBoxing everybody :D Normen
×
×
  • Create New...