Search options (Page 37 of 39)

Well, first and foremost, I would say I'm a 'hardware guy' ( been an EE tech working on radio/communication systems for +25yrs), but the first programming I learned was on an Cosmac 1802 back in the '70s (hand assembly and entered one byte at a time on the front panel. Good times!). I am humbled on a daily basis by the brilliance and creativity that people share on the interWebbies!
So, I am way more comfortable with asm.(but the doc is starting me on new meds); C is all about knowing how to use the pre-built functions and Libs, less about how the processor works, that's a good thing (but hard for a control freak). MIOS is yet another step away from the bare silicon. MIOS handles all the low level IO tasks, so programming an app is a matter of linking the functions in a meaningful way, without having to deal with the details; I.E. reading the SRIO chains, toggling the LCD lines, ect.
And there are allot of very cool MB apps already built, so they only need to be tailored to our own needs, (this can be daunting, I know. You need to understand how the base app works , in order to change it).
The Arduino is really all about this same abstraction from the hardware, that's why it has become so wildly popular. It offers an open door to people with ideas, without forcing them to digest the ATMega Datasheet.
IMO, the MidiBox has evolved into a specialized 'Arduino', focused on handling midi messages and synth HW. Once you get the knack of what the OS and HW does and doesn't allow, the app's logic becomes much easier.
OK, I'll get off the soap box

Oh yes, I know that feeling! Once you start adding this and that, the beast grows; till you need a suitcase.

Well I'm in the same boat as to what to leave in and what to leave out, but the good news is after the HW's built, you can reconfigure it fairly easy!
The only thing that I can offer, and I am reluctant to question your build, is the use of POTs. With a limited CS, you could handle the less used functions via a remote connection to a DAW or Seq, or use a software menu structure to adjust or load new patch values from EEPROM.
But the problem is:  if you want to remotely adjust a variable that a POT controls or reassign the POT to a different function on the fly; you have to deal with the fact that the POT is always reading an absolute analog value that you need to over ride. This leads to sync problems between local and remote copies of the same variable or value jumps when toggling between two variable. POTs are best suited to a 1:1 relationship to a single variable.
Encoders yield relative readings that inc/dec a variable value only when moved, so handling the above issues is far easier. This is why motor faders were used on non-uC controlled mixing consoles and CS' with the introduction of DAW automation. A motor fader's position IS the stored (analog) variable value.
On the HW side, POTs are easier, less complex and simplify the HW, but at a cost of  function flexibility. Encoders allow you to reuse that knob for layers of functions, but you end up needing UI feedback; LEDs or an LCD. A POT's position is the user's feedback, done. With encoders you need two inputs per enc.; so your chip count doubles for the same amount of knobs. If you separate the local and remote control functions, using POTs save space, which for your build is a premium. 
Hope I don't sound like I'm running you down, just trying to point out design options. You may have already considered all these things, in which case you owe me a "Shut Up!!"

MAN, that is sexy!! Really makes me want to gut a flaky Atari 600XL I have in storage.

I think you got a product there!!
Sorry if I bent your ear too much, best of luck!!

Very nice!! Bottom half of ZX case or is it the Nomad? Like'n how you mounted the Teensy. Very cool board fitting. Can't wait to see it finished.
You'r running MB64 on the core? LCD? Very interested in your configuration. Will be very cool to see a CS.
  Just got an NXP OM13000 (same as LPCxpresso brd, but cheaper!), so the plan is heading towards an NG.

LOL!!!

Littlescale, you sir, are a wizard! Seems like you're whipping up a new app every hour!
Looks like I need to get my feet wet with Ableton and/or MAX. Have to start out with an old copy  of Live that came with a sound card I got awhile back. Is the MAX runtime all I need to run the patches outside of Ableton? They won't run within Ableton with out M4L, right?

I know you've worked it out Kineticturtle, looking good.
Just a tip I've used repairing headphone cables (foil woven with nylon thread, GRRRR!). Crimping  loose pins from a DB connector onto the wire helps or telephone spade or butt connectors (they'r made for 22-26 AWG wire. RS 64-3070 or 64-3073). The butt connectors allow a splice with a more  solder-able wire, and the spade can be clipped down in size and soldered direct to a board; no special crimp tool needed, just needle nose pliers.

Love the vids! Really like the grove you got there Aly James, cant wait to hear some on real silicon!
Kineticturtle, Such a cute kid!
So excited!!

<WIPING DROOL FROM CORNER OF MOUTH>
Thanks for the tease !! Could you describe your setup, Is that a modded ZX or just using the case for a Midi CS or step Seq?

I was thinking of it as a good UI starting point, but  yes the MB64 would be the better choice in some ways.
And yes an MBFM is on the 'list' (I've got parts for the FM from one of Wilba's group orders awhile back, waiting for a front panel fab, but 'OH LOOK something SHINY!' kicks in every now and then.)

Yea, for stand alone: that's where I'm going, but tailoring the app to the GenMDM
Not sure how an Adruino would fit compared to the PIC cores, the F4685's Flash/SRAM is at 96K/3.3K., don't know the AVRs that well but I think you would have to go with at least an ArduinoMEGA.

The MB64E uses encoders; minor point but very superior to pots in this app. But really the total count of controls is not the limit. You can have multi-pages per each control. So depending on the size of the Control surface layout, you can 'configure ' knobs and switches to context sensitive functions for each layer, so to speak. Not sure I'm explaining this well, but in essences, if you have 40 switches and 16 encoders you can multiply each control by 2 or 3. BUT the downside can be having too many page to scroll through to get to the Layer/Pram you want to adjust.

Yes the PIC would be a bit more cost effective, but not too much. The cost on a LPC core build runs about $50 US, compared to about $20 US for a PIC core (buying retail parts, but Microchip samples spoil me). So the LPC is in line with a Arduino MEGA cost wise.The LPC seems to be the 'new' direction for MB, and I can't argue with the performance increase. To me, the extra horsepower in the LPC will be worth it. But yea, it would add $50 more to the build then my cost for a PIC core (everything on hand).
Bottom line, can't wait to get the GenMDM in my hands!!