audiocommander

yes there is ;) Regards, Michael

uuh yeah just noticed :-\ the last version should be this one: http://www.midibox.org/forum/index.php?action=dlattach;topic=9718.0;attach=1576 If I can be of any help, just tell me :) Best, Michael

Alternatives to qt301 which will stop being sold on 31st. Dec 07 are: QT300 QT117L See Datasheets (at qprox.com): QT300_102.pdf QT113_105.pdf QT117L.PDF Best, Michael

http://www.midibox.org/dokuwiki/doku.php?id=make_encoders_out_of_your_mouse and http://www.midibox.org/forum/index.php?topic=6348.0 http://www.midibox.org/forum/index.php?topic=967.0 http://www.midibox.org/forum/index.php?topic=384.0 http://www.midibox.org/forum/index.php?topic=365.0 ... or: http://www.midibox.org/forum/index.php?action=search2;search=mouse%20encoder

cool discovery :) I'm currently developing midimouse v06 (for Mac OS X 10.4., Intel & PPC) supporting wiiRemotes. If anybody is interested in Beta testing that would be great: http://www.audiocommander.de/downloads/midimouse_071113_0.6.bC.dmg.zip (440 kB) (If the link is dead, see the original page ) Regarding the Accelerometer Sensors: The remote (as the Nunchuk) just sends out quite raw data of the sensors and there must be some (in terms of microcontrollers quite complicated) calculations to get Tilt/Roll values. The plain Gravity-Force values of the Accelerometer aren't that sexy... Best, Michael

nah... just a Master session with a START but no STOP button ;D

There's an update available! :D http://www.midibox.org/dokuwiki/acsensorizer_04#application_software v0.4.6 / 2007-11: - fixed Master/SLV autodetection bug, now behaves correctly. Overworked areas were Clock-Detection, MASTER/SLAVE auto-switch, feedback-loop protection. - The PANIC button now also sends STOP in MASTER mode (LOAD sends START since 0.4.5) - The Global MIDI Channel now defaults to CH16, messages are sent/received on all channels except for PRG_CH (Global CH only). Now ACS patches can be loaded and saved without interfering with connected instruments. - fixed some minor bugs I also added a MIDI Implementation Table to the Wiki-page. Cheers, Michael ps: of course I'm still interested in reports ;)

Hi Fabricio, sorry, I've just seen that it isn't available at Farnell anymore :( I just mailed someone from Quantum (they have a European Sales Office in Germany) and asked about availability of this chip. I'll come back with the answer (maybe I can organize a batch order or something)... I'd also like to have some of these nice chips, I just ordered a few chips for testing :-) In the meanwhile maybe you'll find something here: http://www.qprox.com/about/eu.php (click on France) Best, Michael

Hi Phil, I'd say that it's very unlikely that a touchscreen is resistance based at all, because resistancy usually requires some pressure that is measured, which would mean that you cannot look through the pad. It is most likely that these touchscreens use a capacity based input grid and these are not the easiest to interface; you need to find specialized ICs to convert the capacity to a readable voltage. If I am allowed to give you an advice: I see you're tending to make it quite complicated, instead of trying with one touchpad, you want to connect 16 pads by PS2 and then you increase the level of difficulty even further by adding not one but two (!!) graphical LCD modules - and an even more complicated touch recognition mechanism. See, overdoing's a typical thing from people being not that experienced (you will find plenty of posts like "I want to build a midibox with 512 motorized faders" in this forum, but to my knowledge none of these ever got built - whereas people starting their projects with four or eight faders usually also build their boxes successfully) ;) If you do not have that massive knowledge in electronics/programming: get yourself a realistic task you can manage. It does not need to be silly or unworthy, but just a little bit more modest ;-) e.g. try with one resistance based touchpad: see if you can find one (and I mean one, not fifty) that you can hook up straight to your MB64, make some tests and you will probably manage this without programming skills at all. Maybe you bought one or two wrong pads, but if you can find cheap used ones that shouldn't be the problem. After that you can try to add a second pad without interfering the signals with the first pad and increase the level of difficulty step by step. If you worked a bit with various touchpads, I'm sure you'll get to the point where you are able to develop a PS2 driver or something crazy like that :) Keep it up! Best, Michael btw: there might be (expensive) touchscreens already interfaced with a IIC protocol, but again, this is advanced stuff, and I do not believe someone without coding skills is able to develop an IIC driver in an ASM based application. Sorry, don't want to discourage you, but one has to be a bit realistic, too ;) Ps: I agree to polosid; touchscreens are probably more useful on a desktop PC rather than on a microcontroller.

Hi Anakin, nice to hear that :) yes, like I said that's because the [tt]DIN_PinGet(pinNumber)[/tt] returns [tt]TRUE[/tt] (1) if the button is NOT pressed and returns [tt]FALSE[/tt] (0) when the button IS pressed. I see this is not very intuitive, but the effect you discovered is quite logic. Best, Michael

yeah, that would be cool :D

Hi Anakin, I'm not sure if I get your question right, 'cause "Snapshot" in this context normally means that it's using motorized pots or faders; anyway; as you can see from the code above it's no problem to ask the analog pins for their current values by [tt]MIOS_AIN_Pin7bitGet(pinNumber)[/tt] and send these values all at once (or you can update a state-array in the [tt]AIN_Notify[/tt] function and then send the whole array or parts of it). You surely know that [tt]MIOS_DIN_PinGet(pinNumber)[/tt] returns the current state of a button (down if FALSE, up if TRUE). That means it does not matter where you send your stuff; it's even thinkable that nothing happens when you turn a pot; just when you press a button, specific pot states are sent, depending on various button states. The best place for this would be the [tt]DIN_Notify[/tt] Function Best, Michael

Hi Anakin, the relevant section is in main.c [tt] ///////////////////////////////////////////////////////////////////////////// // 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 { // check if note on or off event at channel 1 has been received if( evnt0 == 0x80 || evnt0 == 0x90 ) { // if note off event: force evnt2 to 0 for easier handling of 'LED off' if( evnt0 == 0x80 ) evnt2 = 0; // number of DOUT pin in evnt1, value in evnt2 MIOS_DOUT_PinSet(evnt1, evnt2 ? 0x01 : 0x00); // notify display handler in DISPLAY_Tick() that DOUT value has changed last_dout_pin = evnt1; app_flags.DISPLAY_UPDATE_REQ = 1; } } [/tt] So, at the moment, the DOUTs are controlled by sending MIDI-Messages. You have to move the [tt]MIOS_DOUT_PinSet()[/tt] to the DIN-Section and adapt the numbers, e.g. by using a switch case. [tt] ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an button has been toggled // pin_value is 1 when button released, and 0 when button pressed ///////////////////////////////////////////////////////////////////////////// void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { // a button has been pressed, send Note at channel 1 MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0x90); // Note at channel 1 MIOS_MIDI_TxBufferPut(pin); // pin number corresponds to note number MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x7f); // buttons are high-active MIOS_MIDI_EndStream(); // your switch case here // notify display handler in DISPLAY_Tick() that DIN value has changed last_din_pin = pin; app_flags.DISPLAY_UPDATE_REQ = 1; } [/tt] Regards, Michael

Hey Phil, I get the impression you have an angry red face when I read this' date=' I hope I'm not the reason for this, just want to help: That said, it doesn't make any difference if it's a USB or serial or PS2 TouchPad, you need to get this magical voltage between 0 and 5 V to make it work directly on the MB64. You must connect one axis like/instead of a potentiometer on the AIN module. There's no other connection possibility to use it without coding on the MB64. For that reason you need to find the right touchpads, which is not easy, because the technology is normally not mentioned when you buy them. Once you have found touchpads (eg. with 2 times 10k resistance), you can connect as many as you like; Again: there are so many different types around, and without having it here on the desk together with my multimeter, it's just guessing around. I mean, they only cost 1$, why don't you go and buy one and try it out? Michael. ps: AFAIK you cannot order Touchpads from spectraSymbol, they only have custom made types and send out samples which vary in size and type (and hope that you will order 10.000 pieces one day). pps: when Wilba sais "I think this will work", then I would see no reason to not try it. Of course you can use a breadboard for prototyping, so no harm is done here as well.

well... have you seen that it's 6 pages long? ;) and it's not the only topic about touchpads... by code: http://www.midibox.org/forum/index.php?topic=5023.msg46967#msg46967 by circuit: http://www.midibox.org/forum/index.php?topic=5023.msg46541#msg46541 Resistance based X/Y Touchpads (0..5V) can theoretically be connected to any MidiBox, for other (resistance based) touchpads there is the ACSensorizer, which makes use of the first option (ReleaseDetect function). All other technologies have to be converted to output a voltage. I doubt you'll find many touchpads that communicate via IIC (don't think you'll find PS2 touchpads either). There are too many different touchpads / touchpad technologies to give a universal answer that fits them all. Especially if you're not specifying if you want to use it in your own application or in eg. a MB64.

Hi t0gg1e4u, although your code seems mathmatically correct, one should add that the heavy use of unoptimized divisions (and to some extend multiplications) may introduce various codesize and timing problems; surely not if you just turn slowly one knob at a time, but I'd expect strange behaviours under heavy load (many quick changes on multiple inputs). Please understand this as a final comment: if it works for you, it should be fine ;) Best, Michael

home looks good :-) No beer-worries mate, I think the support-level is quite equal, remember your help with the kII / PIC16 baud-sync issue? ;) Cheers, Michael ps: totally off-topic, but I recently started a project page for ACSim on google code. If I got the latest Xcode installed, I'm going to upload the 0.0.8 version and cleanup the wiki. Gotta chat then about the update of the zip (it's not urgent, I need to finish a job before I update my system anyway...)

I'd be eventually interested if I knew the estimated range of the complete prices (esp. of the frontpanel)... I'm on the waiting list since > 1 year now and slowly getting bored... but I fear I have absolutely no use for a PCB without rare parts and a nice frontpanel :-/ Cheers, Michael

Hi, ptitjes created a wiki article about eclipse, http://www.midibox.org/dokuwiki/howto_app_dev_eclipse_ide I think it's always good to have as much information as one can get... if you have something interesting to add that may help others ;) Best, Michael

http://www.midibox.org/forum/index.php?topic=10056.msg74922#msg74922 else see the ACSensorizer, it's a specialized application for up to eight sensory devices delivering not exactly 0..5 V An inverted signal is supported as well (127..0) http://www.midibox.org/dokuwiki/acsensorizer_04 Best, Michael

The question is: why should the userProjects page be doubled? And I just saw that the information on the userProjects page is not the same as on the projects page: http://www.midibox.org/dokuwiki/projects http://www.midibox.org/dokuwiki/user_projects that's the problem with duplicated entries... Another box would scramble up the concept of dividing the projects into categories. I see it exactly the same way as Nebula: So any project that cannot be built at the moment, should not be listed on the project page. My 2c. Cheers, Michael

I allowed myself to remove the unfished ones from the projects page. And I honestly disagree in putting brakes on anything; if someone has an idea to improve the wiki, the structure or add information, I don't see any reason to stop acting. This has always encouraged me to get my ass up and re-act if sth happened I did not agree with. Now shoot me mr. stryd and dr. bunsen Cheers, Michael ps:

dunno, why not LIVE? There's also Sampler for Live. Best, Michael

not sure what you mean by "the code", so I expect you code your own app in C: if you have exactly 2.5 to 5 Vs that's quite easy: Get the value as 10bit... 0-5 V = 0..1023 2.5-5 V = 512..1023 ...and you just have to bitshift the signal (divide by 4) to get a range between 0..127 => [tt](v - 512) >> 2[/tt] no need for complex divisions or multiplications... best, Michael

yes, agreed. "PROJECTS" - only finished (official / user) "USER PROJECTS" - all user projects :) Best, Michael