ruipenha

George, Sorry for this very late reply. Well... I'm sorry to hear all that, and of course I don't have any reason to take it personally! All I can say is that I have a flawlessly working and good quality Motu 896 firewire interface, which I use with a tibook for 4 yeas now. After reading all this, I guess I can consider myself lucky! That reminds me of an experience I had with Esi some time ago, with a M4U midi interface, which I bought new without needing it at the moment of purchase, only because they were selling it in a € 40 promotion, which is quite cheap for a 4x4 USB midi interface with "through mode". I tested it pronto, and it seemed to work fine, with some flaws I then thought came from the absence of drivers to MacOS X. I only found use to it some time latter, only to find it had a few problems that made it unusable (some note events were not send and the latency was not consistent). I sent several emails to them, with details on my experience and searching for help. After several weeks, they answered me they didn't have a clue about what could be causing the problem and had no means (or intention) to help me. I had to buy another interface, this time from another company, of course: a lot more expensive, but working as expected! One thing that stroke me, though, is the 90-day warranty... Only 90 day? Is that possible? In Europe, is mandatory that all equipment carry a 2 year no-fault warranty, I sure hope this is not an excuse for them to send fully tested equipment here and sell the rest there. Again, thank you for all the details, I'll be more careful with my advices regarding Motu in the future. Best regards, Rui

My ignorance... I know of corse that Motu is a Mac thing, and quite an old relationship in fact. But can you please tell me more? I don't want to keep giving good reviews of any product without knowing all the complains other people have... I agree with you... I just had a bad experience with RME regarding their on-board mixing chips and went on to find that they were charging this year's price for last year's technology... I had no experience with their support, but I agree that a good support is worth sometimes more than the difference of the price in two similar products... and I heard that Motu support, specially for us europeans, is not great: I just never had a problem with mine, so I can't complain. Again, and if someone cares about my advice (hey... it's free!), just try to keep away from Digidesign and Esi, two companies with whom I had nothing but unjustified trouble.

Still regarding audio interfaces... I've worked with many fw interfaces - digi002, m-audio, rme, motu, metric-halo... - and I've came up with a personal list: worst of all - digi002 - totally unreliable, mediocre sound quality (for the price) and only works well with protools (the coreaudio drives suck all the power from the CPU and tend to crash with some particular softwares, like max) ok - m-audio, I never tried echo fw, but I've worked with some echo products and I got the idea that they are more or less in the same "quality" class as m-audio. very good - rme, metric-halo & motu this three are quite different, though: metric-halo makes excellent products, but it's a small company and very slow fixing bugs. rme has good products, but they tend to launch a product and then use the same technology (converters, etc...) for a bit too much time. motu - although they used some not-so-good-for-the-price converters in older products, and they tend to be totally silent regarding complains about bugs and schedules for fixing them, their products are great, work flawlessly and have great audio quality. After trying all this products, I ended up buying a 896 firewire interface, and I still think it was a good purchase (which is a rare feeling with technology products when you had them for some time!). They actually have a good line of products now, except perhaps the UltraLite: why spend 624,82 € on this when you can buy the 828 mk2 for 760,42 €? I never worked with the new apogee fw interface, but I expect it to surpass all the ones I referred, from my previous experience with their products: ugly (actually this one is better!), but best-money-can-buy-(-and-you-can-actually-hear-the-results,-ok,-perhaps-not-with-your-edirol-speakers-)-material. I hope this can be somehow useful! Best regards, Rui

Just had to say thanks! Very good indeed... Best regards, Rui

Olá a todos! Falo português, mas sou do outro lado do atlântico! Já construí uma midibox, tenho planeadas mais algumas assim que houver tempo e dinheiro. Quanto a peças no Brasil, não serei grande ajuda (aqui em Portugal é relativamente difícil, encomendei quase tudo pela net), mas qualquer problema que surja posso dar umas dicas em português! Abraço, Rui

Hi again! All done... I have my Midibox configured to: - send note-on and note-off on button activities, from note 0 to note 63 on channel 1; - receive note-on and note-off, again from 0 to 63, on channel 1 and activate leds (please see the remark below!); - send CC from 0 to 63 on channel 1 with pot activities (US users: is it safe to write the expression "pot activities" in a forum? ;D) I find this is the best way to have an all-purpose connection to MaxMSP, using the computer to route whatever I want done. In the examples on the C programming page, I found this example regarding Dout and Leds: ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a complete MIDI event has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedEvnt( unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // a note event provides 128 different note values (0..127) // in this simple example, each note sets an individual pin // for DOUT pin numbers, see also this documentation: // http://www.ucapps.de/mios/mios_pin_list.txt if( evnt0 == 0x80 || evnt0 == 0x90 ) { // 90 xx 00 is the same like a note off event! // (-> http://www.borg.com/~jglatt/tech/midispec.htm) if( evnt0 == 0x80 || evnt2 == 0x00 ) { // Note Off MIOS_DOUT_PinSet(pin, 0); } else { // Note On MIOS_DOUT_PinSet(pin, 1); } } } but I had to change it to (in the last lines): if( evnt0 == 0x80 || evnt2 == 0x00 ) { // Note Off MIOS_DOUT_PinSet(evnt1, 0); } else { // Note On MIOS_DOUT_PinSet(evnt1, 1); } } } for it to work, as the compiler complained (funny expression! "compiler complained" :) again, please note that I'm portuguese, not native-english speaker!) that the variable pin was not declared. I don't know if it's merely my mistake, as I've never programmed in C or done any midibox activity before, but now it is working correctly. Best regards and thanks for everything! Rui

Hi Smash! Funny, I've just ordered a core kit from you... I guess soldering is like programming: first you hate it, then you crave it... Yes, I tried the B solution... but I found that there were two things I didn't want happening: - the midi in was getting out (midi-merge, I guess) - I couldn't light up the leds ??? - some buttons and leds wer assigned to midibox functions, and I don't have any LCD (lazy me...) I guess I'll step in to MIOS programming, the documentation in the codes given is so good I don't think it should be a problem. Still, if anyone has some ideas that might help me, you're welcome!! ;D Thank you all, I'm really starting to feel I've joined a good community! Rui

Hi! Thanks for your quick reply. Yes, I know my douts and my dins! It was only a mistake when posting the question... The link you gave me was good, although my knowledge in C is zero, nada... I guess it's time to start working on that! I'll look at the programming side and post new questions as they arise. When I finnish my Midibox, I'll also post some photos of it, as I documented all the process. It's actually an instrument to play live, controlling 5 computers at once. I have no problem on the computer side, the electronics part it's a bit difficult, as I was a total virgin on this subject before starting this project. My midibox will control audio synthesis, video synthesis, sampling, granular synthesis, all done with MaxMSP & Jitter, that's why I would like to have simple commands from the Midibox and then translate them via computer software to do what I need, as it is very simple to implement midi control in Max. Best regards, Rui

Hi! I’m finishing my first MidiBox 64, which was built in a modular way (hardware) in order to be able to change the interface (acrylic rectangle with buttons, pots, leds, etc.) and keep the same pcbs, ports and wooden box. As I’ll use it to control my own programs in MaxMSP, I would like to have the following configuration always active: 2 x Ain – from CC1 to CC64 (or from CC64 to CC127 if that’s difficult to implement), all on midi channel 1 2 x Dout – from midi note 1 to midi note 64, all on midi channel 1 2 x Din – I don’t really understand how can I light the leds, if possible I would like to have it configured as note-ons and note-offs, from midi note 1 to midi note 64, all on midi channel 1 (or 2 if this can cause problems with the above Dout configuration) Also I would like to disable the core function that sends midi notes it receives in the Midi-Out plug (midi-merge?). Sorry if this is really an easy subject, but I uploaded the MIOS .hex and Main.hex from the MidiBox64 folder, using a difficult PC (I’m a Mac user ;) and I can’t seem to find the information I need to get this done. Also, I’m sorry if my English is not as good as it should be, but it’s not my native language. Best regards, Rui Penha