audioworld

...I also just discovered it via matrixsynth and wanted to post this.-)) yes, very nice, especially because the pic file is short and easy to read, the circuit could be build with verowire in one hour I suppose.. useful!

therezin, I do not really get the point: you want to control 3D-models from your MIDI keyboard? I klicked around on the 3DC website and they have this very nice controller with assignable buttons and a LCD display: http://www.3dconnexion.com/products/3a4b.php in the forums there are detailed descriptions how to adress the LCD directly: http://www.3dconnexion.com/forum/viewtopic.php?t=1095 mhhh, very slick hardware...

has anyone ever tried using a SpaceNAvigator as a musical instrument interface??? http://www.3dconnexion.com/ It seems this would be a perfect device for soundbending, filtersweeps or more complex parameter control. They have a quite helpful and active developer forum and a SDK online, and the company resides near munich, germany: http://www.3dconnexion.com/forum/ maybe we could even connect those encoders directly to MB digital inputs before they hit the USB bus.... regards, karl.

from the ever-evolving thread about the LIVEAPI over at the ableton forums, here are the OSC commands which the MONOME can handle at the moment: QUOTE: OSC Out: /box/press OSC IN: /box/led /box/led_col /box/led_row /box/alloff (same as /box/clear I assume) /box/intensity /box/shutdown /box/test In my OSC implementation (monochrome vst), besides box/clear on startup (to quickly blank all 64 LED's), I only use the two "most important" messages (/box/press and /box/led) which both have 3 ints following (x,y,bool state), e.g. "/box/led 0 0 1" (enables top-left LED) UNQUOTE. so this leaves me with the impression of a VERY simple box, again... regards, karl.

I gathered some additional information regarding thorstens earlier question: "...What I don't like on OSC is (but I could have missed this in the past), that there is still no solution for a client to find out which parameters are supported by an OSC server..." here is a pdf paper from 2004 on exactly this topic: http://a2hd.com/query-system-open-sound-control but the names added just recently this comment: "...This work will be superceded by a forthcoming publication on recommended practice for integration of Open Sound Control with Web Services. The material is provided here for historical purposes....." along this line a found a thread in the OSC-forums, where the query mechanism within OSC is declared "flawed": "...However, my current line of reasoning is that putting the query system into OSC is technically flawed for a number of reasons (e.g. violates the state-machine-free requirement and also needs assured delivery), and furthermore is a redundant effort because query systems have already been defined in more appropriate meta-languages and are already sufficiently expressive for our requirements (e.g. web services)...." another interesting finding for me was "Open Sound World": http://osw.sourceforge.net/ this really seems useful to work with OSC on a practical level, I will try this out for sure: http://osw.sourceforge.net/html/osc.htm my next links points us to OSCULATOR: http://www.osculator.net/wiki/Main/HomePage although it looked promising at first sight, it is MAC only, and does not support MIDI input, just midi output... there is an interesting free plication called CPS, they also have (basic) OSC implementation: http://cps.bonneville.nl/manual/appena.htm#OSCparam finally (ta taaa!), here is a library with the "best match" for thorstens remark: http://wosclib.sourceforge.net/doc/index.html they provide several complex methods, one is "callback list": http://wosclib.sourceforge.net/doc/index.html to me this sounds exactely like "polling an OSC server for its available methods" of course, I will also look into CHUCK and PD, but I do not think they have the query mechanism implemented. BIDULE could have this, but it is not free any more, and I do not want to shell out 69€ just to find out what it can NOT do..---)))) best regards, karl.

thorsten, your specific question about finding out the parameters offered by a server seems to be covered theoretically, I found this reference on the cnmat.berkley.edu site: "Query system to dynamically find out the capabilities of an OSC server and get documentation" Now I will dive into google to look for a real-world implementation of this feature... regards, karl.

stryd: wouldn`t make sending ARRAYS and strings via OSC bidirectionally make many "conversations" with the host app much easier for some MB applications? MIDI always just sends one or two bytes per message... I do agree that complex "intelligence" should reside in the host app and not the interface, but I still think that most MB applications could benefit from a more efficient exchange protocol...

thank you tk, maybe I am just a little "envious" at the MONOME crowd, they have all the attributes like "hip" and "cool" connected to their poject, whereas MB seems just so much more powerful to me, or did I miss something (i.e. the monome is box with 8/16/64 lighted buttons..)??? As I just checked, it also connects via SERIAL to the PC, no USB or MIDI or ethernet... also, tk, how would a SIMPLE OSC MB controller application connect to the computer? MIDI and then convert to OSC with some python code???

I suppose you all read the big news in the "scene" from yesterday: API calls for Ableton Live via Python! http://liveapi.org/ with the LiveOSC code one can access many internal LIVE objects directly (clip names, colors, clocks.) as well as get some response from LIVE about what the user is doing on the GUI. Basically, the Python code is accessed by assigning a "virtual" controler surface within LIVE. As I was playing around with OSC, Python and CHUCK some weeks ago, I found some interesting properties of OSC when compared to MIDI in this thread of the Ableton forums: "...OSC can send arbitrary blobs, floats, ints, strings -- as well as arrays of those values..." http://www.ableton.com/forum/viewtopic.php?t=66118&start=0&postdays=0&postorder=asc&highlight= Unfortunately I am not a "coder", but theoretically, this development makes me think if the MIDIBOX of the year 2012 (or 2010?) might not have two MIDI-Ports and no USB port, but one Ethernet-Connector, and sends/receives OSC commands to the host application. I have no idea if this is within the capabilities of a PIC, but I want to ask the experts about their thoughts, as for me, this is the first real paradigm shift away from MIDI towards a more capable protocol...

cleepa, I have some limited experience with the monome, CHUCK, MAX, Ableton Live and Midibox so far: I think MIDI is much more flexible at the moment than OSC, especially when adressing standard VST hosts and plugins. Take the Monome crowd for example: they have to use a special CHUCK script in the background to convert from OSC to MIDI for Ableton Live control... maybe you could try the reverse approach: use the MIDI bytes from a Midibox and convert those to OSC network commands via software. I think I saw a PHYTON script which can do this, also CHUCK would be something to look into. I myself use OSC to control CHUCK variables from a software GUI fader via a PHYTON script, it can not be too hard to make this GUI fader respond to incoming MIDI, too. Look also into PROCESSING, PD and/or TAPESTREA, as those are all working in a MIDI/OSC crossover environment. good luck, karl.

as I am much more an audio engineer then a ASM/C programmer I like this thread..--))) I worked with various "cans" over the last 22 years as a balancing engineer, and came to the conclusion that headphones (much more than speakers) are very personal. some of my professional colleagues really like headphones which I could not stand for a minute and vice versa. despite having all kinds of AKG´s (240DF="Diffusfeldenzerrt" ist der Beste), Sennheisers (the HD25 is to harsh and thin for my taste), Beyers etc... in our inventory, I really like the SONY MDR7506 the most. powerfull, nice bass, not too much high end, great. I do not know if you can still purchase those, but a similar model should be available. Those also fold down nicely if you have to pack them.

david, as an audio engineer not looking at RAM consumption in the first place, your problem to me sound more like an audio card loosing SYNC. do you use digital inputs? I am asking because a similar sound effect can be introduced when you start with proper sync, then loose the sync, the soundcard tries very hard to keep up, and finally streches the audio. something similar happend to me with a large ProTools rig which was synced to a DAT machine, which switched off after 1 hour of not touching it (this happend during a live radio broadcast...----))))

TK: I also thank you for the clarification, most welcome.

i am glad that you ask this... I myself so far could not figure out how the .ini-file and the other files for midio128 play together.. I asked this question in the forum already, but never got an answer which gave me real insight. The values for the buttons and knobs are also defined in mios_tables.inc, and I do not know if the values from the .ini override those, if they complement each other, or if they are suspended if the same button/knob is already defined in the mios_tables.inc. after all, an .ini-file is only provided for midio128 and no for the other main.asm (like midibox64), and for my limited knowledege of C and assembler the documentation of the ini-file does not explain the context. Hope you get a decent answer to this one, would also help me...

hallo auch, als wiener bestelle ich manchmal bei neuhold in graz: http://www.neuhold-elektronik.at/ die haben zwar nur ein kleines angebot, das aber sehr günstig und liefern prompt und zuverlässig. vorige woche habe ich 200 dieser netten kleinen taster bekommen: http://www.neuhold-elektronik.at/catshop/product_info.php?products_id=1442 20 stück um nur € 1,20, damit baue ich eine 128er-matrix... schaut dann fast wie ein kleiner octopus aus: http://www.genoqs.net/15010/index.html gruß, karl.

to henrygr: thanks a lot for the infos and links, I just received all the parts for my box, will be soldering the next days, then I look into the code again.

henry, sasha, I also think that you can not compare Cubase and Live. I use both, but for different puposes. Live as a tool to try out combinations of loops, plugins and sounds in a quick way and for playing live on stage. Cubase for more traditinonal songwriting, although the "track view" in Live is so good now that I think one could avoid Cubase altogether. Overall I found that integrationg Audio/MIDI plugins with multiple routings is much easier in Live then in Cubase. Yes, I just tried it with Live 6.0.7, one CAN invert CC´s, just by typing 127 as the minimum and 0 as the maximum value. Also, with CC´s multiple assignments are possible, the crossfader works already (AUX SEND PREFADER and TARACK VOLUME on the same CC but inverted). The "curve" of the crossfade is not good, it seems only linear behaviour is possible between 0 and 127, so the Track fades out too slow and the AUX comes in too slow, too.... It is not possible to assign one NOTE ON to multiple destinations, though. This is a pitty, as I want to start multiple clips with one button, I guess I have to set up SCENE for this purpose...

ok, I just have to ask this again: what use does this "midibox64e.ini" file have? If one has to define the MIDI codes inside mios_tables.inc, it seems redundant to me to also do this in the ini-file. which file "wins"? thanks, karl.

hi ultrasound, I am not very experienced myself, but as I read a lot of forum postings and WIKI entries during the last weeks I might be able to help you a little: 128 buttons and 64 pots are possible with one core, there is also basic code for this configuration which I will use myself in the next weeks: http://www.ucapps.de/mios/ain64_din128_dout128_v1_3.zip if you unzipp this, you will find many files in the folder, DO NOT PANIC! Open the "main.asm" with a text editor, you find precise instructions which software you need and how you can compile you own new "Main.asm", tailored to your needs. the whole idea here is that the application is MODULAR, and various parts oft the code reside in the .h and .inc files. You should buy a preprogrammed PIC from SMASH (US) or MIKE (Germany), as this gives you the basic MIOS application already as a start on board, and you only have to upload your own "main.asm" via MIDI Sysex with MIDIOX. this is quite simple, like sending sound patches to a Synthesizer. Most of the .h and .inc files are not relevant to you (and to me) at the moment, they are just needed to define the registers, functions and memory spaces. Focus on the "mios_tables.inc", here you will find the MIDI codes which are sent by the buttons and pots. HEY, this will be easy, no need to make a new "main.asm" for the first eyperiments: when I look at the entries now, it seems to me they are by accident configured excately the way you need it. buttons send controllers 0-127 on MIDI channel 1 (hex B0 xx), and potis send controllers on MIDI channel 2 (hex B1 xx). So take a deep breath and dive into it: Just order the preprogrammed PIC (with MIOS on board already), solder your core together, take the ready-made "main.syx" and send it to the Core via MIDIOX, connect your buttons and pots, and make some good music! hope this helps, karl.

hallo u, bin selbst eher "newbie", doch gerade bei einer ähnlichen entscheidung. der unterschied zwischen 64 und 64E ist nur, dass die E eher encoder und keine potis bietet (kein analog-in), daher wäre diese entscheidung enmal wichtig (potis ODER encoder). Der crossfader ist aber analog, daher wäre doch ein design mit der 64 (ohne E) firmware ins auge zu fassen. Ich war auch sehr verwirrt über die vielen möglichkeiten einerseits, die beschränkunge der unterschiedlichen firmwares andereseits. das gute scheint mir aber, dass man ja jederzeit die firmware umspielen kann, wenn der core einmal spielt. Ich habe nun die ganze theorie beiseite gelassen, das hat mich nur verrückt gemacht, ich warte auf die teile von MIKE, baue den ersten core mit einigen tastern und potis, und schaue mir das dann praktisch an. Gruß, karl.

hallo Thorsten, danke für deine Antwort. Der Tipp mit der ain64_din128_dout128 ist gut, die sehe ich mir mal an. Ich habe meine Benutzeroberfläche auch schon fertig, die Teile von MIKE sollte ich nächste woche bekommen, dann kann ich endlich in die Praxis gehen. Ich schreibe auch schon offline an einer doku über mein Gesamtkonzept und hoffe, dann insgesamt etwas konstruktives für die "Gemeinde" beisteuern zu können. Soviel vorab: ich möchte mir verschiedenste kleine Controller-Oberflächen (eine jeweils nur eine Eurokarte 100x160 groß) bauen, jede soll dem Bildschirm-GUI eines der Plugins die ich benutze möglichst nachempfunden sein (z.B. RONIN, Reaktor-Ensembles wie "Synth in a Case", Beatlookup, FourTechre). Je nach "gig" möchte ich dann drei dieser Oberflächen mitnehmen, und an die Cores anstecken. Das Besondere dabei sollte sein: Die drei Cores sind nebeneinander in einem 19 Zoll 1HE Gehäuse fix eingebaut (dieses steckt dann in einem SKB 19 zoll 3HE Case direkt vor mir, mit einem Sherman-Filter in den oberen 2HE) und sollten alle den gleichen Code benutzen (nur jede auf einem anderen MIDI-Kanal, und mit Merge durchgeschliffen sein). Man sollte also nichts umprogrammieren müssen, wenn man die Controller-Oberflächen austauscht, und kann je nach Lust und Laune auch recht schnell und günstig neue Oberflächen bauen können (da nicht immer ein Core benötigt wird). Von dem Core-Gehäsue führen dann kurze (<30cm) Kabel mit 15-pol Sub-D Stecker zu jeweils einem der Controller-Oberflächen. Ich weiß dass dieses Kabel kurz sein muss, hoffe aber dass es auch die Steckerübergänge "schafft", mal sehen. Damit werden die Oberflächen aber wirklich kompakt, da man kein MIDI-Kabel und kein Netzteil anschließen muss, und auch der Spannungsregler und das Core "ausgelagert" sind. Gruß, karl.

hallo doc, danke für die ermunterung! Ich baue grade ein Feld mit 128 Tasten und mit 128 LEDs, um Clips in Ableton Live und Samples in KONTAKT zu triggern. Dann habe ich auch schon die Teile für eine MB64e, um dann Regler und Potis für einen Mischer "drumherum" zu bauen. Den Zusammenhang zwischen MIOS und den Applikationen verstehe ich noch ganz gut. Ich hänge dann nur an diesem ini-file, das schaut ja zunächst sehr verständlich aus, dann aber hat sich mir die Frage gestellt, ob die Einträge in diesem ini nach dem Upload in den PIC in die Applikation (main.asm des MIDIO128) hineingemappt wird, oder ob das ein unabhängiger Speicherbereich ist, der nur von main.asm heraus abgefragt wird. DANKE: der Tipp, dass die mios_tables.ini in der MIDIO128 main.asm nicht eingebunden ist, hat mir schon mal geholfen!!! Die Frage hat sich mir dann noch gestellt, dass ich von den 128 tasten gerne 8 verwenden würde, um die anderen 120 quasi umzuschalten, zB alle gemeinsam auf einem anderen MIDI-Kanal senden lassen, um mehrfache Bänke von je 120 Clips oder auch Samples in KONTAKT abfeuern zu können. Dafür würde ich ja diese META-Events benötigen, um Bankstick-Speicher aufzurufen. Die Definition für diese 8 Tasten habe ich aber im ini nicht gefunden, und bin deshalb in den vorhderhand frustrierenden Schlammassel mit dem main.asm und den ganzen Includes gerutscht... Ich danke nochmals für dein Hilfeangebot. Wenn es dazu keine einfachen Antworten gibt, werde ich das mal so fertigbauen, und dann mit neuem Anlauf in die Sache gehen. Liebe Grüße, karl.

also, ich bin wohl zu blöd dafür. habe nun insgesamt 8 stunden lang alle diese .inc, .h, und main.asm files durchgearbeitet, sowie all die text- und info- files über mios und midio128 und mb64e und so. das war eher verwirrend als dass es klarheit gebracht hätte. ich habe mal selbst vor 20 jahren 8051 in assembler programmiert und dachte, da komme ich irgendwie ran, aber die einzelteile sind einfach zu unübersichtlich für mich (aber natürlich sehr leistungsfähig, das sehe ich schon ein). dieser mix aus assembler und c auf rund 50 (bei mb64e) einzelne files verteilt... ich durchdringe z.B. noch immer nicht, wo denn nun wirklich das maping zwischen din/dout und den MIDI-befehlen erfolgt: im mios_tabels.inc oder im .ini-file (das ist mir auch noch immer unklar, ob ich das ini-file NACH dem midio128-syx-upload nochmals draufspiele) ich verstehe, dass ihr nicht zum 1000x einem einsteiger dies erklären könnt, 99,9% der user hier sind ja schon auf einem ganz anderen niveau. ich gebe mit dem code jetzt mal auf, und benutze mal was ich habe ohne modifikation, ist ja ohnehin toll was da alles möglich ist. alles gute und danke für die viele basis-arbeit, karl.

thank you, skinnsky, I thought the 6.x update only enables the SCALING of the CC´s. Is a multiple assignment of NOTE ON´s also possible (e.g. one note on triggers two clips)? If yes, Ableton will receive my update payment asap, cheers, karl. PS: I should try to code this simple rule anyway, just to practice..---)))

good remark, although I think at the moment Ableton Live at the moment does NOT allow to assign the same CC to two different targets, or did I miss something? In my version 5.x it always warns me that the CC will be de-assigned from the previous fader... karl.