Jidis

OK, I ate about 10 lbs of Chinese food and got the sudden urge to move the three lines of code which throw the status of the LED toggle variable (LED_TEMP) on the screen. It was in the buttons.inc file, right at the start of the general purpose button function, before some code that checks to see if button 24 has been hit. After that, it would invert the variable and exit. I moved it to the tail end of the mb64_leds.inc file, just before it tests the temp variable and lights (or clears) LED#24. If I move it to the very end (right before the LED update's "return"), it ruins any light status testing, just like it did when it was in the button handler. The variable still flip flops on the LCD, but the light stays in one state. This is all that was involved: call MIOS_LCD_Clear movf LED_TEMP, W call MIOS_LCD_PrintHex2 ;; shows the status of LED_TEMP What gives?? All in all, it works. It isn't the most responsive thing I've ever seen, but it's tolerable, and it doesn't affect any of the other light's functioning. George PS-- OK, now the sucky part: That thing with the LCD_PrintHex2 is just something I was using for peace of mind, so I could tell that my variable was actually being toggled. It's not anything I would want on the screen (that's what the lights are for). I now find that removing the LCD junk completely is the same as having it in the "wrong" location (no more toggle light). Why would those three lines affect the simple testing of an unaltered variable?

Thanks Thorsten :) I see what that's doing (dumping them all out directly, one by one, rather than running through each of those routines in the loop), but I guess I'd still be responsible for getting my "changed" register's contents into whatever DOUT_SRSet call it went with. When I first read this, I swapped the update routine with that list of SRSet's, and got about the same as before, but with an "inverted" output (all LED's on, and they'd turn off during each corresponding button press). The 24th light still did the same thing, where it changes for a second, and then gets wiped out. I guess with the contents of all the MB64_BUTTON_VALUES_SRx's being unchanged, that's what I should expect. Been messing with it a lot and will continue to do so, and I really appreciate all the help. One thing I did find while playing with it, was that I can throw PinSet's and stuff at the very end of all the calls under the MB64_LED_Update (right before the return), and it has no choice but to use them. I guess it's actually quickly clearing them with the real code and then immediately setting them with my instructions at the end. Appears to work somewhat anyway. A strange catch to that, is that I can't for the life of me get it to reliably use any sort of bit test or "zero checking" code at the end of that update, to either clear or set the 24th light (depending on my LED_TEMP variable). Right now the buttons.inc still has a couple lines in it that throw the LED_TEMP state on the LCD every time a button gets toggled, and the variable gets comf'd every time button 24 goes down. You can see an "FF" in the corner of the screen and watch it change to "00" when you toggle #24, but the test at the end of the LED_Update seems to always find a zero. I've tried a couple different conditional branches at the end, and it just doesn't work.??? ??? ??? Sorry for all the hassle, George

Yeah, someone in the Nuendo forum already suggested setting up a "thru" arrangement, but it was messy. I didn't mess with it long, but to begin with, I found out you had to set up a dummy track and put it in record mode just to get started. It seemed mainly set up for recording MIDI tracks (not really controller stuff). I'll look into it again later, it just struck me as weird that it would totally ignore the same changes when they were made from an outboard control. I'm not sure it's worth it for them to get into adding anything to it though. They've got guys in there with WK Audio ID controllers and what not. >:( >:( On the plus side, it's supposed to be sharing a bunch of code with Cubase these days, so perhaps it would be helpful to a few of them. I'd guess all the controllers with dedicated drivers (or emulated ones) have nice, solid two-way updates happening from the DAW. Most generic users probably aren't dealing with a bunch of outboard LED's on the receiving end either. Admittedly, I still don't know much about the MIDIBox's emu apps. Maybe one of them would do the trick. Damn shame for this EQ thing I made (three friggin' lights total). Take Care, George ---- apologies again for the off-topic, Villadon ;)

Thorsten, Much thanks as usual! I think I understand most of what you describe, but I get pretty shaky toward the far end. Keep in mind, I'm still barely on a 16f84/small app sort of level, so the MIOS apps still contain lots of instructions I'm not familiar enough with. I'll be reading up on the ones I need for this. I had looked at using the PinGet function for something a few days ago, but hadn't looked into the full SRget ones. I probably should clarify my intentions. As a "for instance": -Say I've got 16 channels of lights and buttons to handle mute & solo across a mixer. -I only wish to have a single button, per channel, with a global mute/solo switch (switch has two corresponding lights, plus that variable to show you what the mode is). -The actual LED map will remain unchanged throughout (the mode toggle won't affect it). I want a constant visual indication of each channel's status, and the lights will stay mapped to the incoming MIDI events for whichever registers they're set to. My "guess" is that I'd need 5x DOUT SR's (16 mute LED's, 16 solos, and a couple extra pins of a fifth one for the toggle indicators), then just three DIN chips (16 mute/solo "combo" buttons, and one extra button for the toggle). Guess #2 is that I'd be seeking to pull in that whole 5th DOUT SR's contents, set or clear only the bits (pins) that I'm using for my mode lights, and send it back where it was, to be used by the rest of the LED update. BTW, I'm not ruling out the possibility that the 5th DOUT/3rd DIN would have nothing else happening on them (that was just an example). I'd need the rest of that DOUT SR's pin status to remain intact. Sorry if that's what's happening in the example code you gave me. Again, I'll be trying to get a better grasp on a couple parts of that tonight. I can see where it's cycling through the registers and where it's checking for where to begin the map, but it still looks like it's dealing with each of the SR's as a "whole" (unless I'm missing something). Really appreciate all the help, George

Sorry to come back to this, but I've gotten a bit frustrated with the amount of time I've spent on this one thing, and the idea that I may save myself if I could just get a quick pointer from someone else. My light is still getting killed off, and it appears to be happening within the MB64_LED_Update call in the mb64_leds.inc file (I can jump out of that with a return, and I'm OK). Is there anything similar to the button handling filter, where you can pop in a "literal" button number and jump out if it sees that? I'm getting worried that the LED stuff is more a matter of looping through every single light's current value, and that it would require me to get *my* value inside the group of LED statuses (ouch!). Thorsten and all- This is just a regular MB64 app (no LED rings or anything in the source). The idea works OK using an old "small skeleton" (1.6), but there's no LED's happening in that. The MB64 is currently in that mode where the buttons and lights are tied together 1:1, but I've tried others. The button handler is set to ignore the button I'm using for this, and that works well (no LED or current button change when I hit that one). Thanks Again, George PS (FWIW)- I'm trying to work out a "permanent" version of the shift mode thing, with a toggle (only active on the downstroke of the button), to put me into a second group of output messages. A variable keeps track of which mode is active, and gets inverted by a "comf" on each pass through the toggle code. The LED would be tied to that, so you could tell by looking at the box, which mode it's in. Ironically, it looks like everything else is working OK. I've added a couple lines to dump the toggle status variable onto the LCD each time to make sure it's right, but that update loop is still shooting my light down the second it goes on.

Don't know if this is good or not, but dakro69 David has gotten hold of some "weird" displays which are HD44780 compatible: http://tinyurl.com/nk3e9 They're "buy it now" for $32.99 and are supposed to be up near 100 dollars for a current DigiKey version. I've dealt with him before with no problems. Don't know what the deal is on his user name. It's now exdwh_com, but it was dakro69 (it's still Experimenter's Discount Warehouse). Take Care, George

Yeah, it sounds like you're trying to do what I wanted to do. As Thorsten says, the host app will turn the light off and on, but for that arrangement, I guess you wouldn't want them tied to the button registers, just to the corresponding MIDI events. The important part is in getting the right prefs set in the DAW app. Nuendo and Cubase have got a whole assortment of flags you can set, and they default to only "receiving" the MIDI signals from the controller. If you set the transmit flag, they'll spit the same message out whenever the item's status changes. Well, they would in a perfect world, but evidently they don't in this one. Turns out they only put one out when the change is made from the computer (with the mouse or keys). If you toggle an item from your remote, the status changes in the program, but nothing goes out, and your lights are then out of sync. I've been meaning to get in here and see if anyone could come up with anything good on the MIDIBox side of it, to make the setup work right, but I'm afraid it's on the developer. I'm thinking, in my case, maybe using an emulation mode would work, but I wish I could stay in generic. Sorry for the subject changing sob story, but it's all related I guess. I hope your program is better about it than mine. ;) George

Thorsten, Thanks. I probably need to work through this on my own. I've been wrapping up some outside projects for a while and have forgotten some MB stuff already. :-[ Going through the current skeleton app, the MIOS functions ref, and the LEDs.inc file, it looks like there's a few different ways to turn them on anyhow. I may try some others. Much to learn, George

Sort of a confusing title I guess. 8) Thorsten mentioned in a shift key thread, that you could prevent your chosen shift button from triggering any of the usual events, by filtering it out in the "buttons.inc" file: ;; exit on event from button ID = 0x10 movf MIOS_PARAMETER1, W xorlw 0x10 skpnz return In that case, it was at the beginning of the MB64E_BUTTON_GP function, where the user was making his other edits. How/where do you safely kill an i/o pin's connections to the rest of the MIOS activity? (I guess the above was one place) I was tinkering with the use of one of the LED's as an indicator for something and was noticing that something was immediately turning it off after my dedicated button turned it on. Like something was updating the output shift registers and wasn't aware of my change. The pin itself (I believe) shouldn't have been linked to anything else. I had it set to receive an unused high register's MIDI notes or something. Thanks! George PS (if anyone can answer this one too) That "general purpose" area of the buttons file is just global code, which all button events will ultimately pass through right? - I know there's that general purpose button section in the main file for some menu specific functions.

Ouch, yes :o :o I'd check those six times before committing to any copper. ;) With the lights set to link to a button bank's MIDI messages (like with mine) it still seems like you could assign them to an unused higher bank, and then assign those buttons the same values, but in the correct order to match the real bank. I've learned too many times now that it's easier to fix it from the start though. George PS- You'd probably also be really screwed if you were using the arrangement where the lights are tied directly to the buttons (not the incoming MIDI).

Bill, Keep in mind the actual part pinning varies from brand to brand. I've learned the hard way on the duals. I've got at least two different pinnings of common anode dual digit here. I'd like to see what you're doing with them regardless. I like those things. :D George

Thanks Thorsten :) Rewiring them is no big deal. I just figured doing something weird might be a good learning experience anyway. I was going to look into that deal on mapping them to a higher (unused) button group anyway, to see why that didn't work later on. Been back to messing with shift keys again on a new box, and it looks like you talked to someone named Neomorph a couple years back about it, and he used a shift key to switch his button messages, by doing something similar (knocking them up by 3 or 4 shift registers). He only had 8 buttons, so I guess that means that the assignments for the subsequent button groups are still valid and available. I'll try to figure out why that didn't work here. Thanks Again, George PS-- Looking back, I don't think I've made one board where the i/o pin order was correct. 8) I double check the crap every time, and still end up with something screwy. Just finished a new test box yesterday, and the lights and buttons are fine, but three or four pots need to be jumped around.

Hey again, Yeah, they're not actually part of the app zip. They're in that zip bundle on the mk_syx page here: http://www.ucapps.de/howto_tools_mbsyx.html I think there's one in there for most of the main apps, but I was just using the regular MB64 ini. There's a bunch of good settings in that file, and it builds and dumps to the box really quick. Take Care PS- That Perl install was a bit on the heavy side here. I'll look into it later, but I'm guessing the part that we actually must have to build the syx files, may not require everything that was put on there by the install (? ? ?). Sort of like the way MPASM was. I can actually run that from a folder with little more than the exe file.

Great videos.>:( Maybe a fellow German can get him to explain what the hell it was that he ran the transfers through for the lamination. 8) He describes the traditional iron method, then proceeds to feed the board through something that looks like either the guts of a laminator or a laser printer, stuck to a piece of plywood or something (at 4x video speed of course). Wish I had that. I really want to move everything to a laminator for consistency at that stage, but I'm not doing it until I can find something that's proven to handle fairly thick stuff (even metal if possible). Wish there was a detailed DIY page for something good. George PS---- Spoke too soon :o Looks like it's here: http://thomaspfeifer.net/laminator_temperatur_regelung.htm but it is in German and it is 6am here, so I'll pass for now.

Villadon, I've been playing with the MB64.ini lately using the mk_syx to make dump files (see the post right under yours). I just sent mine a syx to check, but it looks like changing any of the items in the [bUTTONS] section of the ini to "@Toggle", will do what you want. I set my LED_SR to link to the corresponding button shift register, and put them on toggle mode. They now come on when you hit them and stay on until you hit them again. Hope that helps. Still wondering about the LED map in that other question if anyone knows, but it looks like Steinberg may have a glitch in the generic remote implementation which is going to screw me up worse than any map could. :-[ George

Hi again, I'd like to coordinate the light/button arrangement in a MB64 app, and was wondering if it were possible somehow in the MB64.ini,etc. The order of the LED's doesn't match up with the buttons I'm running. Is there any way to assign specific note values to the individual LED's, similar to what can be done in the [bUTTONS] section toward the end of that ini file? I've got the [LED_MAP] set to link them to "MIDI Status received for Button ID #1-#8", which works, but the order's wrong. I've tried assigning them to an unused button group (#25-32 for instance), and then changing the note values in that part of the list to what I wanted, but it didn't seem to work. The box only has one SR each way (in and out), so the app prefs may have killed off that part of the list. (??) Thanks! George

Thanks again, I'll probably tinker with that one now too, just to see what it does. :-* It was good to see the other one get changed so easily and work. The time I spent playing with the button mode and weird LCD layouts on another box was a PITA >:(. Felt like there was always some area of the app where the change wouldn't end up working right, or wouldn't get called at all. That XOR in the pots file will probably suffice. This thing's an EQ, and nothing more :). I may try to get in and look at the actual scaling/range stuff again to fix an issue with the crossover points on some stepped controls. I don't know if it's an unavoidable part of the VST spec. or something, or if the plug developers can control it, but the highest range of the stepped controls actually gets triggered at the value of 127(!). I guess that means if there's even the slightest bit of jitter on the pot line while it's at 127, or if you should bump the controller with your knee or stare at it for too long, it's going to jump down a notch into the previous value. Probably be nice to have it quantize anything over 120 (there's 4 to 6 steps in my case) up to a full 127. Take Care, George PS- I also wish I could have gotten by without using three 16 pin IC's for the i/o. I haven't done the main board yet, so I'll probably at least dump the 4051 and go direct to the core for the 7 pots, but there's only 3 buttons and 3 lights, so I've got a full 595 and 165 in there. I've got some boards from a JLCooper controller here, where it seems they had a 4051 and maybe a 74**164(?) for each of the 8 channel sections, and they had mixed up the pot/switch/light arrangement somehow, so that the same shift/mux chip was handling two different tasks.

stryd_one (or anyone else), I tried tossing an XOR in the pots file, within that section on scaling. Seems to work fine at the top of the section: However, I remember from trying to add a button mode to the source a while back, getting everything working with some weird source tweaks, and later finding one area/page or something where the new item didn't make it into the program flow. With the XOR placed there, am I safe at *all* points where the pot values might be used, or should I move it somewhere else? Much more thanks, George

stryd_one, Thanks! I figured I could resort to that sort of stuff, but didn't know if maybe Thorsten had a "range" pref in one of the files or something you could just reverse, to get the values turned around. If you've got a minute, where would be the obvious "safe" place to do that, where it wouldn't risk screwing up any other reg. contents or flags? Thanks Again, George

FWIW, I really liked the knobs on the notorious Alesis 3630 compressor, and called them to try to do that once. They told me they had a "maximum" on that, and they could send me a certain amount (just a few), but it wouldn't have cut it for what I wanted. It may be one of those deals where it depends on who you catch on the phone, and what they ate for breakfast that day though. It also may have been the quantity of that particular knob that they had on hand then (I think he went and checked). They sent me a brand new body for an HR-16 once, free of charge, and it showed up in a couple weeks. Also, I'm considering dipping or painting some knobs with liquid latex (craft store junk) to get that same feel you're looking for. It's colorless when it dries, and I've also had luck colorizing it (black only) with latex paint. It seemed like it would work if you mask off or plug up the areas you want to keep clean. It's cheap too (under 10 USD here). Good Luck, George (and let me know if you see any "3630 looking" knobs, ideally with no index mark ;))

Hi, I hate to be lazy about this, but it's 6AM here. :-X Is there a simple means of flipping the direction of pot travel in one of the MB64/MIOS files (pots.inc maybe)?. To meet my usual quota for the minimum of one careless mistake per PCB, I've got a small switch/light/pot board now, with the 5v and ground lines reversed to the pots, so they all go counter-clockwise to get from 0-127. Sounds easy enough to fix, but they (the grounds) are also tied into three switches and three resistors for some LED's on that same board, so there's no really clean place to flip the main lines, without getting all that crap involved. I'll look at the traces tomorrow when I can think again, but if it's something that can be knocked out in software, it would be a relief. This box doesn't even need a display, and the app will be more or less permanent and simple (7 pots, 3 LED's, 3 buttons). Much Thanks, George I've been fighting with other parts of this current box all night and

Ruipenha, I'm a MOTU user myself and can ditto everything stryd_one said, but unfortunately, there's a few more nasty angles to it than just the notorious Windows software issues. I was up their ass pretty bad for a while in the Unicornation forum, but figured it wasn't worth the time it took, so I came out (for the time being, anyway ;) ). Some aspects have always been really bad (the busy signal telephone line and "invisible" public relations come to mind), but there seems to have been a gradual change in some other areas, which doesn't make them look all that great. I'll try not to get into too much detail, but for a couple: They seem to have locked down every major recording/music magazine over the past few years via advertising funds, as well as building a questionable influence with some of the larger chain stores and websites where you might find reviews and organized "recommendations". There are issues with their support, as well as certain known problems and incompatibilities with various hardware, which, IMHO, never really makes it through any of those channels. I'm not implying that it's some major "conspiracy thing", it's more just that they seem to have sort of "evolved" as a successful business, by finding out what areas were most profitable to focus on, and went that route, with no intention of correcting any of the problems. Some have actually gotten worse, but whomever it is calling the shots there, obviously does not care to change them, as long as the bulk of the current and future customer base is kept unaware. Myself and others have been totally ignored by support, over repeated inquiries, and then had them suddenly try to contact us directly, only after mention was made in the public forum (which they don't participate in). They're also well known to respond with insulting "cut & paste" suggestions from their FAQ info, and usually don't continue to help, after they realize that the customer actually understands his/her equipment, and has a legitimate, common problem, which needs to be resolved on MOTU's end (or can't be). The failure rate I witnessed from hanging around the UNation forum, was sort of the "last straw" for me, and it helped to explain their ability to keep the costs as low as they usually are. They almost seemed to anticipate a certain (high) percentage of failures, and had set up a support system where you basically pay a flat 80 bucks to have a refurb sent out or something. It sounds like a great deal, but they also only carry a 90 day warranty, and every active user over in that forum seemed to have had some experience with sending their interface back at some point, and somehow they were OK with that. Many have reported sending back interfaces more than once, and having the same issue or failure with the replacement. It really didn't make any sense to me. The stuff doesn't really have any moving parts, yet it often died on people within the first few months. You can't expect much more at those prices, but it really is "mass-produced, disposable junk". Not that there's anything wrong with that (some of my favorite gear is "mass-produced, disposable junk"), but MOTU should be seen as such too. Their history of horrible customer relations and driver support doesn't earn them anything more than what we all throw at Behringer, Alesis, Mackie or anyone else. I only own one Behringer piece right now, and I actually like it, but I've had no serious failures with a whole slew of Alesis & Mackie junk, and the support is miles above MOTU. Well, to be truthful, some of my Alesis crap has some pretty flimsy "moving" parts, but I've never had any of the core circuitry go south on me. The 424 MOTU system, on the other hand, scares the hell out me. It works fine now, but I really have no idea of how long it might work. Even if it never croaks, it definitely would not likely be guaranteed compatible with any boards which came out a few generations after it was current. MOTU's "officially supported" list leaves much to be desired, even when the stuff is still on the shelves. No offense to Ruipenha, or any fellow MOTU owners here, and I hope none of our stuff gives us any significant amount of grief over time. Take Care, George PS- If you want to read any of it, there should still be a decent amount in that Unicornation hardware forum under "Jidis" from a few months back. Someone else was picking up where I left off when I slowed down. There's usually at least a couple "summarizers" in there. 8)

Bosone, Don't know if you've already seen it, but there's a 16f84 project which can take you directly to MIDI, if you ever want to use it without the core: http://kaele.com/~kashima/games/bmconv/index-e.html He's got source on there too. Take Care (and happy 222) :) George

Moebius, Thanks for that effort. :) I think that's the same one I've got on my controller keyboard, and I can't stand it. It's clunky and sticks up out of the panel, keeping you from setting drum machines or anything on it. ;D I usually keep it out, but the stupid keyboard defaults to some "split" dual channel mode or something, so I have to make a couple settings whenever I use it. I wanted to see what was in that cart a while back, and maybe install one inside the Roland instead. I never really have more than one patch (or two) in it. Was that the only thing in it? I didn't see a datasheet for that, just those sleazy links to people trying to sell me the specs. Thanks! George

DrBunsen, That's funny, Synsonic pads were my first drums about 25 years ago, thanks to a "gimmicky" Buddy Rich commercial. Didn't take long to figure out they had no relation to real drums, so I bought a snare and went in for lessons. Wish I still had them though. ;) The Simmons head for my pads was making a nasty ground buzz, years ago, IIRC. I may have enough junk now to open it and try to check/replace some stuff to make it work. It's got blank holes for MIDI, but the pads and stuff are on the PCB. It would be great to have on there, if anybody happens to have one with the MIDI option. I can check the guts to see what chips look to be missing, but there's probably a firmware image which I'd need to find too. I "thought" mine was an SDS-1000 (8 drums with one sampled sound for snare). Take Care, George