Jump to content

ultra

Programmer
  • Posts

    832
  • Joined

  • Last visited

Everything posted by ultra

  1. it'll actually be 5 colors i suppose, since we need one color for a playing clip, and another for a stopped clip. i don't think the dogxl are overkill at all. if i'm gonna use an lcd to display clip names and other information, might as well have enough space available to show it properly. track select, solo, mute, etc, i think should be on the mixer.
  2. btw, is there already a schem for rgb matrix? i found the duoled one but the forum isn't searchable, getting database errors.
  3. no kidding nils, my seq went thru so many iterations as i learned more about electronics. ended up costing me a lot of money. i've made a new layout for the clip trigger device: now i have 2 dogxl lcds, a custom FPE case, and plenty of room for additional controls. going the custom case route is more expensive, but in the end i'll have exactly what i want. for a main mixer box, motorfaders are absolutely possible. so is showing track names, eq and other parameter values, etc. now anything is possible.
  4. haha :) i'm looking at making my own case design anyway. unfortunately this project is quickly getting expensive.
  5. after some more reading, i realized that front panel express makes it kinda easy to build a custom case. gonna try to work something out tonight.
  6. krisschneider: apparently tk's link to the blm will allow 7 colors (per bugfight, thanks). i do have the ability to not only read live's clip colors, but set them as well. perhaps the grid could be limited to these 7 colors. for instance, if you try to select one of the 60 colors in live that doesn't exist to us, it just forces it to the nearest color. also, preset patterns could be stored in the midibox and set in live. but this is all details, the blm is a bit daunting to me and i have no idea how it looks via code, but i am thinking this is worth doing and i'll figure it out as i go thank you tk, this will be perfect if i can get the leds to actually fit under the buttonpads. again, thanks. 80 lines across two displays would get me 7 chars + a space per clip name, plus an additional 7 chars on the left side for something else (assuming 4 tracks + scene names on second display). i think this is worth doing as well, and i'd really like to find a way to put the lcds in the same box as the clip matrix. it just stinks that there aren't many desktop type cases available. if i removed another row of clips, it would fit into that seq case, but i'm not sure how you feel about handling non-seq orders with this tk.
  7. the screen keys would be fun to play with, but i can't see a midibox driving enough of them for a clip grid. i don't think there's any support for a matrix of rgb leds. i certainly don't want to design it or write a driver, not that i'd know how. i'm not that advanced of a programmer. i think that if we can't have infinite colors, then two should be enough. what would you use the third color for? apparently there's a configuration of the blm that will strobe the red/green for a yellow effect, tho i'm not even sure that's necessary. i am able to read clip names and colors into the midibox, but to implement it i would need a specific purpose since i'm no longer making this in the same way i was before. i do think it's a shame to have the ability to read clip names and not put them on the midibox. if i could find a bigger case, i'd add an lcd. also, features i might want to add later should have an lcd anyway. but the problem is finding the right case that's easily available and at the right price. i see this box as also being useful as a drum programmer and step sequencer, and i'd need an lcd for configuration. also, a big lcd would be needed to display clip names for 8 tracks and six rows, plus scene name. if you wanted even 6 characters per clip name, you'd need 62 chars across, including spaces. i'm not sure the DOGXL will even have this. there are probably displays that are this big, but i'm not sure if any drivers are written (also would have to be cheap and readily available).
  8. the reason i want to use the pac-tec pt-10 is because it's compact, inexpensive, and easy to get. the idea is that anybody will be able to build this without having to build anything custom. if you know of another case, tell me plz.
  9. i haven't much discussed the other projects. ideally i'd like them all to fit into PT-10 cases as pictured above, but i'm not sure things like motorfaders will work well. main mixer: will allow you to control 8 tracks of volume, pan, etc, bankable. also controls the transport, bpm, toggles session/arrangement view, and can include various other functions such as undo/redo, hide/show browser, hide/show detail, etc. for the most part it will look like a regular mixer. as an option, banking the tracks can cause the red grid to move, and the trigger box to change accordingly, and vice versa (all these boxes will have the ability to follow each other via the live script). dj box: a 2 or 4 track box specifically designed for djing. will include volume controls and crossfader, as well as eq controls (non-detented rotary encoders) that automatically map to the eq device. it also can include encoders/buttons that allow you to select a scene and fire it. bpm control of course. crossfader assign is also possible, but as of right now that's one of the few live functions i haven't been able to figure out. instrument programmer: i've been able to scan for available instruments and automap, in a sense, to their controls. my idea for an instrument programmer is one that detects the active instrument and adapts to it. initially, you'd have to set up the knob/switch box for how you would like the layout to be. but then these can be stored to an sd card, and recalled automatically. so whatever you're doing in live, editing a clip, instrument, etc, this box can follow and adapt. lcd: this would be the last box i'd build, if i'd make it at all. it's possible to download track/clip/scene/device/device control names to the midibox and display them on an lcd. if i could find a big enough lcd to display the information i want, you could virtually eliminate a computer screen when playing live. it also could be used as an add-on for each box listed above. for example: you could show the names of the 8x6 clips and scenes that you have highlighted on screen. or, show the parameter names you're controlling with the instrument programmer. i have the ability to load almost any piece of information i want regarding live into the midibox. but it might make more sense to find a way to add the lcd to the other boxes. just some thoughts, this is a lot of work and all in the future, but like i said the hard part is done and these things are all very possible. ultra
  10. the problem with the colors is that i'm limited to 2 with a duo-led matrix. but i think that perhaps there's another way to identify which clips are loaded onto the trigger pad? perhaps a preview button that you simply hold while you tap a trigger, and then ableton live puts the red box around just that clip until you release the button. that is quite possible and also very easy. in fact, i think i'll implement that into the app right now. currently i'm using a trigger finger for this, but i'll get around to developing a control surface pcb soon that will include the livid buttonpads. regarding issues with the faders, you can do whatever you want with motorfaders (if i were to use them in one of the projects). when the midibox first starts up, it asks live for whatever existing parameters are necessary. so the motorfaders could simply move to the appropriate location. also, when you open another live set, it'll adjust accordingly. definitely not looking to earn anything from ableton. they don't support the liveapi hack, they just allow it to happen. if you have more ideas regarding this button grid (keep in mind that a mixer type, dj type, and instrument type are in the future) please feel free to let me know. ultra
  11. synchronizing a motorfader or led ring could be done pretty easily, since these values are automatically updated in the midibox if i write the code to do so. if you want to create something custom for yourself, you'll have to know how to code in C and python. otherwise i'm open to getting some help in designing the other controllers, which are a main/mixer type, and an instrument programmer/knobbox. ideally i'd have them in pt-10 cases since they're easy to find and work with, but i'm not sure if motorfaders, plus other devices, will fit into them.
  12. i have started the design for the first of a series of ableton live controllers. this controller will be a clip triggering device that automatically integrates with ableton live (that's right, no configuration or midi mapping whatsoever) using a liveapi script that i've been working on for quite a while. the hard part is done, which is a communication protocol over midi that allows a midibox to seamlessly communicate with ableton live. that means that you can build this box, plug it in via usb, select the control surface, and start triggering clips. front panel design (tentative, adding more controls is possible and i'd like some feedback): the buttonpads: this grid will allow control of an 8x6 grid of clips. i wanted 8x8, but there wasn't enough room. still, it's +1 over an apc40 ;). the 7th bottom row is for stopping clips, and the 9th row on the right is for scene triggering. the encoders on the left will select which set of clips are controlled by the grid (x/y). the screen will show ableton's red box that the apc40 uses so you can see which clips you are controlling (box is movable with the encoders): underneath the buttonpads will be bi-color leds. automatic feedback from live will turn on the led of a clip is present (off if not), turn green if the clip is playing, turn red if the clip is stopped, and blink in beat time if the clip is queued for triggering. the stop buttons will light up red if a track doesn't have a clip playing (i suppose this is more for looks/consistency), and the scene buttons will show which scene is launched. the case will be an easy to get, relatively inexpensive pac-tec pt10: i am hoping to use the same case for the rest of the series of ableton live controllers. i'm looking for feedback from anybody who would be interested in a kit. the kit is not yet guaranteed because i haven't yet asked tk, and i'd have to look into feasability/prices. i think this box could be pretty easily built for under $200. maybe much less. i would like to continue with a series of kits which will work in a modular fashion (picture 3 PT-10's on your desk, each with a different form of control) and all of which will communicate with live automatically, with no midi mapping. once i get going, i could create additional controllers pretty quickly because the hard part is done. keep in mind that there's not much room left on the panel, so there will be no lcd. a few more buttons/knobs for additional functions are possible. let me know what you think and what should be added. thanks, ultra
  13. midibox live is rockin - i have a trigger finger that lets me change that red square (like apc40) and trigger clips!

    1. ultra

      ultra

      all with no configuration necessary, i might add.

  14. i've put a lot of work into integrating midibox with ableton live, and have had good results. project description here: http://midibox.org/dokuwiki/doku.php?id=midibox_live i was going to create what is basically an API to allow others to code their own midiboxes that integrate with live, but i think that it's a lot of work for so few programmers, and it will leave a lot of people out of the loop. also, it's hard to decide how far to go with it. there's so many forms of control and communication that i've been able to expose to a midibox, and i don't know when to quit. it might be better to tailor this to specific projects. instead i've decided to turn this into a modular system. the goal is to create a set of midiboxes that do different functions for live. master control, clip matrix trigger, instrument programmer, and perhaps even pattern/sequence designer. that way many people can use this technology (maybe kits?), and only use what they need. for instance, if your need is to control the master section of live, and the mixer sections for 8 tracks, you can build the midibox designed for this. if you need 16 tracks, you can build a second one. same for clip control, perhaps a midibox designed for 8x8 clip triggering, or a second for 16x8 clip triggering. in the end, you'd have a scalable set of midiboxes in pactec pt-10 cases that only do what you need, all of which automatically and completely integrate with ableton live behind the scenes using liveapi. sure, you'd have a lot of separate boxes to build, but you can use only what you need at the time you need them, instead of one big, difficult to build box that controls all functions, but is more generic. so far, here's the ideas for the different midiboxes, all in pt-10 cases: master section: designed to the mixer section of 8 tracks, and also master control. for the tracks you'll be able to control volume, panning, eq, and various other functions perhaps. for the master section, you can of course play/stop and control view (session/clip). i suppose scene triggering could be added to this. if 8 tracks isn't enough, you can bank them or build a second one that will control the next 8 tracks. clip trigger: a 9x9 grid of buttons (perhaps livid's? for clip control. 8x8 for clips, a row for scene trigger, and a row for clip stop (if necessary). bi-color leds will show if a clip is present (led off if not), playing (one color), or stopped (another color). a blinking led (synced with beat time ;)) will show a crip is going to be triggered. your set of clips will be highlighted on-screen by ableton's red box like what you see with the akai controller. the set of clips to be controlled can be moved around via rotary encoders or buttons, and the leds will follow where you go automatically. the clip names can even be brought into the midibox, but i think it would be a problem trying to find a kit ready lcd that's big enough to show names for an 8x8 grid. instrument programmer: it's possible to scan ableton live for the available instruments on a track, and a box could be created that automatically assigns itself to the available controls. some initial setup would be necessary, such as assigning the correct knobs and buttons to what you see on screen. but once this setup is done (perhaps configurations can be stored to an sd card), you can drop an instrument on a track and have the midibox automatically assign to the controls you want. parameter names could even be brought onto an lcd. if you select a different instrument in live, the box can automatically follow you and reassign its controls to whatever instrument you've selected. this would be the most difficult to code and the last i would build. just a few ideas i'm throwing out there, i still believe that using liveapi is the way to go because you can integrate most of it without any kind of setup and no additional software layer (like MFL). the midibox can just read what live is doing and set itself up, and also automatically control what you want in live. a modular system allows you to use only what you need, and also simplifies programming because instead of making it all universal, i can tailor the code to specific needs. also a modular system will be scalable, so if you need 16 tracks, just build a second box in a compact pt-10 case. all boxes can plug into a hub using usb and communicate directly with live (and of course, live will communicate necessary information to ALL midiboxes, so if you change a track bank from the mixer box, the clip box and red grid will follow). these will all run on core32 for various reasons (mostly because core32 is f'n awesome). i hope any of this makes sense, i got a little tipsy last night and it's carried over into today ;) edit: nothing major, a lot to make tho. but i don't feel like it.
  15. what kind of case were you going to put this panel in?
  16. back in midibox action!

    1. stryd_one

      stryd_one

      Must be something in the air ;)

    2. TheAncientOne

      TheAncientOne

      Must be, I'm just starting to do stuff again too after a 12 month layoff.

  17. hard at work on midibox live

  18. this is still in the works, and it's going great!
  19. the number i'm working with right now is 84. i tried dividing by 10 to see what happens, and i get 8.0. so for some reason it's rounding off or just removing the decimal.
  20. yeah i don't really get it. i tried: (float)decValue / 1000 (float)decValue / 1000.0 (float)(decValue / 1000) it all gives me .000
  21. also, to be more complete with information, not using / 1000 gives me this: 00000021437039 ms | 1267 00000021437039 ms | 474 00000021437039 ms | 474.000 so it's sorta working!
  22. ok here's a code snippet. i changed it to /1000 and directly set the first values, even though i'm getting them in a different way. i have this: int intValue1 = 1267; int intValue2 = 474; float decValue = intValue2; float totalValue = (decValue / 1000); DEBUG_MSG("%d", intValue1); DEBUG_MSG("%d", intValue2); DEBUG_MSG("%d.%03d", (int)totalValue, ((int)totalValue*1000) % 1000); and end up with this: 00000021173501 ms | 1267 00000021173501 ms | 474 00000021173501 ms | 0.000 1267 and 474 are values i received from live, which started as 1267.474. in the end, i want my 474 to return to .474 so i can add the 1267 to it and get my original value back. i haven't done the final adding operation yet because i want to get the .474 working first. thanks, ultra
  23. thanks a lot tk, that works quite well. i'm also struggling to understand this: my float is always a positive int (i guess that's obvious since i was creating it using an int). for the correct value, the decimal should be shifted 3 places left. i multiply by .001, but i end up with .000, at least using what you gave me to output to mios terminal. is there something else i must do? i would think this would work in most cases, but is there something specific to the compiler regarding floats? too much OOP has spoiled me. i have to work with ints in the first place and convert them back to .001 of the value because i'm bit shifting some values to 7 bits, sending over midi from ableton live, and reassembling them on the other side. i didn't see a good way to just send a floating point value (doubt there is one) so i break up the values before and after the decimal and send them separately. so this is the part where i try to reassemble it on the other side. ultra
  24. i know this is simple stuff, but for some reason i can't get it. i have an integer that i want to turn into a float. int intValue2 = MBLIVE_TranslateFrom21Bit(&val2); float decValue = intValue2; DEBUG_MSG("%d", intValue2); DEBUG_MSG("%f", decValue); for sure intValue2 gives me the number i want. i read online that i can simply assign an int to a float and it'll become a float, but my second DEBUG_MSG just outputs a blank line. i also tried using (float) before the int and that didn't work either. any ideas? thanks, ultra
×
×
  • Create New...