Jump to content

SilverZero

Members
  • Posts

    22
  • Joined

  • Last visited

    Never

About SilverZero

  • Birthday 01/01/1

Profile Information

  • Gender
    Not Telling

SilverZero's Achievements

MIDIbox Newbie

MIDIbox Newbie (1/4)

0

Reputation

  1. I thought it was "climate change" now.
  2. I'm feeling like the hardware is the hard part, the software isn't really coding per se, more just finding out what parameters to edit in the existing MB applications. I'd bet you could find instructions here or at the dokuwiki for anything you want to do. Unless you want to totally add a new feature or write a whole new app, you shouldn't need to do any coding from scratch. And multiple patches would probably fall under the "Bankstick" category - lots of info there, too. :)
  3. So, I'd like to elicit some closure to this conversation. (Kind of a true/false prompt here.) Detented encoders pose a mechanical limit to the resolution, because one "click" of an encoder may actually run through four events. Non-detented encoders will feel smoother, like a pot, and will offer un-encumbered resolution down to the level supported by the software. There is a software "fix" to either decrease the resolution to compensate for detented action or to allow progressive "acceleration" for faster sweeps. Or both. There is no requirement that one use either detented or non-detented encoders - it is ultimately a matter of personal preference and your own requirements (higher resolution, quicker sweeps, tactile feedback/feel, etc.). And in the end, with the right software tweaks, all of the limitations of a detented encoder can be removed. But you can't add tactile feedback (clicks) to a non-detented encoder. True or false? :)
  4. Haha, yes, I know. It's a joke (and a quote from a TV show).
  5. I have no idea. You're lucky I could put this much together for you. :) If you do think more about this, you should note that even the LTC module can be pared down quite a bit to ONLY run the MIDI-Thru function (as in, you could build the circuit with just the J1 interface, IC3, R5-R8, C8, and J4 and J5 for the MIDI-Out/Thru ports). I don't see why you'd even have to include the IC2 socket (it just controls the activity LEDs) or the IC1 circuit (it controls the interface to the COM port). If I'm wrong, somebody please correct me, but they seem to be three separate circuits that only share +5V and ground, so removing one or two of them shouldn't be a problem for the remaining one(s). At that stage, you'd almost be better off just wire-wrapping the components on a piece of matrix board instead of buying the whole LTC PCB. In fact, after this discussion, I'm almost leaning toward building my Core on a matrix board with the IC3 circuit integrated, as it's so simple to add it on. Cut out the LED controller and the COM port, and you've got a pretty basic little MIDI-Thru add-on! If you haven't seen the LTC schem that TK made, here's the PDF: http://www.ucapps.de/mbhp/mbhp_ltc.pdf EDIT: There's actually a straight MIDI-Thru circuit design already isolated and schemed here: http://www.ucapps.de/midibox/midi_thru.gif It's very similar, just omits the 2nd MIDI-Out port, along with the bypass cap and some other pin connections that must have to do with the MIDI-Out signal. 1 IC, 2 resistors, and a few solder points is all it takes to add the Thru port! (This is mostly for my own reference when I build later.)
  6. One option would be to have basically two separate controllers housed within the same enclosure. Then build an LTC module that gives you a MIDI-Thru port. You would then chain the MIDI-out of the MB64 affair to the MIDI-Thru on the LTC, then back out to the MIDI-In on the SEQ affair, or vice-versa. Then the MIDI-out of that second device would go out to your DAW, obviously. LTC at the wiki: http://www.ucapps.de/mbhp_ltc.html So it's like building two separate devices, then chaining them together with the LTC, but then mounting everything in the same box. I'm sure there are more elegant solutions, but this is one idea. :)
  7. I may have to do some testing with this and report back. It sounds like the signal may not make it without proper amplification from the pedal board. Does this mean that I can't just rely on the power output from the core to the AIN to return the signal strongly enough? Ugh, I'm hoping to avoid having to use two PSUs for this project.
  8. Thanks cimo, Do you mean I need to power the AIN somehow, or just make sure I have a good power supply to the core? (10-12v, 500+mA or so, right?) And as for coax cable on the analog part, is it the shielding that's important? The only coax I know if is a single conductor with a shielded jacket, and the AIN connects to the core through a ribbon cable (10-14 wires). Right?
  9. Is there a "safe" or even documented limit to the cable length between an AIN/DIN module and the Core module? For example, is it feasible to mount an AIN and a DIN in a foot-pedal chassis (foot buttons and expression pedals) and connect it to a separate "main" controller enclosure that houses the core and another set of pots/buttons/LCD/etc.? I saw somewhere that MIDI specs put a 50ft. limit on cable length, does that apply here as well? The total distance between the pedal board and the enclosure would only have to be 2-3 meters at most. Thanks!
  10. Could be - I'm always keeping one eye on my 18-month-old daughter. :)
  11. @ Simone and SLP: I must admit, I completely spaced the whole digital/analog thing when I was thinking about this. I've spent hours reading about all of that in the past, I have no idea why my brain was so out of it. I'm mostly trying to defend my intelligence, for what that's worth at this point. ;) But I do understand how buttons and rotary encoders differ from analog pots. I guess my head was somewhere else the other night. Anyway, thanks again for the input.
  12. I bookmarked your tutorial for a go-to reference when my parts arrive. Thanks for all the effort!
  13. Simone: I'm sorry. Thank you for all the info in your last post. Yes, this probably should be in a different forum, now that you mention it. Yes, it would probably be better to build a MIDIBox using documented methods. This all started because I got curious last night, and wanted to play with it today. Ordering parts takes time and money, this was supposed to be an alternative. In fact, it was really just a learning project, and I was looking for direction. I guess I'll just have to build a MIDIBox by the book. Of course, that's what I said a year ago.
  14. I'll try to clarify: Since I already HAVE a full-size MIDI keyboard, I want to convert my little O2 into a controller with more buttons or pots than it already has (8 of each, plus the octave and mod levers, which are kinda lame but may be useful as rotary encoder inputs). In other words, if I can take a controller with 8 pots and a bunch of keys I don't need to use, and transform it into a controller with 8 or MORE pots and 25 BUTTONS, or some combination thereof, it would be more useful to me. I also want to do it with the parts I have and without programming. If I had money to spend at the MIDI store, I would do that, but this is a project for fun, just to see what I can do. Isn't that how this whole community started? Mike, thanks for the info. I noticed the two switches, that makes sense about the key velocity. I guess that means I can't use each of those contacts for a separate button, right? (Or possibly for velocity pads for percussion. . . .) About the pots: I see that the key contacts are actually two parts each, separated by a small space, so the key must close that circuit when it presses down and bridges that space. My thought was that I could bridge that space with a pot instead, but then I came to the main question of all this which was whether the signal would even go through correctly (since a note is just on/off, whereas the pot sends a variable voltage, and notes don't really have any variance included besides the velocity, which is taken care of by the dual-switch thing). Is my thinking correct so far? Thanks for the replies!
×
×
  • Create New...