ultra

I'm looking for a couple midiboxers who use Ableton Live and have an iPad. Currently, all my app does is trigger clips and do a few other functions (mute, solo, arm, loop clips) over network MIDI (using an excellent network MIDI library maintained by our own Kurt Arnlund). But I'm adding more features, such as automatic hardware remapping. It'll kind of work like the APC-40, except you could build your own midiboxes or controllers you've bought and automap them in a few ways using the app as an interface for it. You also won't be limited to a single controller, as any combination of controllers can be mapped to different functions and changed on the fly. For example: you could have a controller with 8 volume faders that remap with the clip grid to control volume for whatever group of 8 tracks are selected at the time. The knobs of that controller could remap to macros on each track. Then, another controller could become whatever device you have selected at the time, or be an aggregate of your favorite parameters from different tracks that you could "page" through to remap, or perhaps drag a parameter name from a list to a knob and remap it on the fly. The app isn't designed like LiveControl, where your main focus is on the app. Instead it's designed for people who are busy with their hardware. You can trigger clips without taking your eyes off of Live, because you can touch the iPad, drag to your clip (there's an on-screen preview showing which clip you'll trigger), and release to fire the clip. You can also navigate around the clip grid by dragging or swiping. Currently, it's not much different than other clip trigger apps on the app store, but i think the hardware integration might set it apart. I can't offer any kind of payment besides a free copy, but your ideas will definitely be heard and it's an opportunity to help make this app be something you'd enjoy using, especially if you're into building hardware and want a way to extend its uses. For anybody just interested in the existing version of the app, please find it through my website at http://www.sub-version.net (sorry for the shameless plug). For anybody interested in testing, please ask via private message. Any discussion of the app just post here. Thanks! ultra (a busy guy who can't wait to get back to midiboxing)

I'll try it later tonight and let you know what happens. The .hex itself is what you upload to the core. ultra

I'm kinda new to Mac and I haven't used xcode as anything but a basic editor. I have programmer's status, but my understanding of the toolchain isn't the greatest so I just follow the wiki instructions. ultra

plz do! i'm using xcode and make -s from the terminal. i'd love to see my errors highlighted among all those warnings that i ignore for now and will get to fixing later. :P ultra

i've looked at their buttons before for one of my projects, but the button/spacer layouts aren't correct for me. it's an ableton live controller so i thought soft buttons would be cool, but i always return to the tact switch and led configuration. it's cheap and easy and works fine. i never noticed that the brain is $189. seems expensive compared the price of an LPC17.

i'm not positive, but your message might be an upload request. did you check your contrast?

so does gfx_1322 call into font.c to get the bitmap data? here's where i'm confused: i want to write the text "midibox" to the display, starting at x/y coordinates 16/32 with a shade of 8. i'd assume that the function would have to be specific to this display, since others might not have shades, or might even be rgb and then have a color argument. so would my function to write text actually call into gfx_1322, like this? print_text("midibox", 16, 32, 8); then gfx_1322 loops through the characters, passing each one into font.c and getting back the bitmap data on a character which will then generate the 1322 specific code to write pixel/shade data to the buffer? if this is correct, then font.c is doing nothing more than translating the hex codes into 1/0 data and returning it to gfx_1322.c for buffer and output.

i have this working and i'm able to access .bitmap[x], .left_shift, and .width from my mios32 app. i'm assuming the next step is to make a font.c that handles drawing the font from the hex values? should this somehow implement the standard mios32 display functions? i'm not sure if that would work because we can add parameters such as shade, position, etc, for each character or whatever we want. also i plan on making some general use meters and perhaps some other graphics. so should the standard mios32 display functions be ignored and i write my own display printing code from scratch? ultra

here's the output from two iterations of the main character input loop: #include font.h character superpoint_square[] = { { .bitmap = {0xc000, 0xc000, 0xc000, 0xf800, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, .left_shift = 0, .width = 5 }, { .bitmap = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, .left_shift = 0, .width = 0 } }; now what? :P edit: nm, i think i got it.

i'm a little confused. i don't see an 'extern' definition. does it go like this? extern character square_font[] = ... font.h shouldn't be generated, but maybe it'd be easiest for the programmer if i output that to its own file if it doesn't exist? you said the .c file should contain the font data, but isn't this the font data in the .h file? .bitmap = { 0x0... it's looking like i'm closer than i thought to having this completed. all the pieces are in place. ultra

i've written most the font generating program and it's working very well. it's pretty user friendly. but i'm stuck trying to combine the information at the page you linked with how it should be in this context. should i end up with a .h file for the structs and a .c file for initialization? so far, this is my output. i only put in two characters b/c i could spend all day testing this with 96. the series of hexadecimal numbers include the left_lead (now called left_shift) and width. but i'm assuming i don't have to do that since i'll be generating the initialization code. anyway, here is what it looks like so far: struct character { u16 bitmap[16]; u16 left_shift; u16 width; }; struct font { struct character characters[96]; }; struct serialized_superpoint_square = {0x0, 0x0, 0x0, 0xfe00, 0x200, 0x200, 0xfe00, 0x8200, 0x8200, 0xfe00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7, 0x8000, 0x8000, 0x8000, 0xfe00, 0x8200, 0x8200, 0xfe00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7}; this is of course not in the output. it's what you see as you build a character. 0/. is used for input to make it easier to see, and it's later translated into 1/0 for the hex output. ................ ................ ................ 0000000......... ......0......... ......0......... 0000000......... 0.....0......... 0.....0......... 0000000......... ................ ................ ................ ................ ................ ................ 0............... 0............... 0............... 0000000......... 0.....0......... 0.....0......... 0000000......... ................ ................ ................ ................ ................ ................ ................ ................ ................ sorry for my lack of understanding with what to do with this, but at least when this is done we will be able to do some really cool things with this display. :) ultra

well that was easy user_input = "0000100110001110" total = 0 for bit in range(0, len(user_input)): total += int(user_input[bit]) << (15 - bit) total = hex(total) print(total) 0x98e now i just need a bunch of instructions and loops and formatting and whatnot. :)

in my program to output the serialization, do i have to define each character like this? for instance, here's a lowercase 'a' in superpoint square: 0000000000000000 0000000000000000 0000000000000000 1111111000000000 0000001000000000 0000001000000000 1111111000000000 1000001000000000 1000001000000000 1111111000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 i left 3 px above it for uppercase letters extending upward, 3 px below for lowercase letters extending downward, and the unused 0's underneath. ignore what i said before about 11px fonts. this is 13 overall. this one is designed assuming the 0,0 coordinate is at the top-left, but it could be changed to the bottom-left. anyway, those specifics don't matter as much right now. what i'm wondering is how i feed this into a serialization program? do i 'draw' each character like this, then write the program to loop through the lines and output a hex value for each set of 16 bits? if that's the case, i get how this works. just loop through the data, making a string with the hex value and concatenating a ', ' to the end. copy, paste into my C program, and repeat. or write in all the chars and have it output the information once. also, does the serialized data contain left_lead and width information? 96*18=1728, so i'm assuming the two extra 16 bit words include the information. therefore, to retrieve the character's width, does it look like this? width = myFont->character[0].bitmap[17]); thanks for helping, i'm learning a lot about programming that i didn't know. i'm going to try to start working on a python program to output the serialized data.