stryd_one

Why not share the one channel between the two devices?

I strongly recommend the use of one or all of these FireFox addons, to make this forum and wiki (and all others) easier to use (such as creating links, quotes, images etc): CoLT - You can copy hyperlinks from anywhere on the web to the clipboard in forum or wiki format, ready to simply paste in place. (also does other formats, rather handy in general) BBCodeXtra - Puts commands for forum code in the context menu Text Formatting Toolbar - Gives you a firefox toolbar like a word processor for forums The first two are pretty much a must-have for me... The third is a nice extra. Offtopic a little, but 'snaplinks' is also an easy way to open all the posts from the unread posts page. HTH!

It's probably worth your time to read through the forum (search for MBFX to see some ideas, I try to tie threads together using that term) but you seem to have the general idea, of how to get a core to talk to a synth (fingers simulator) in general.... The tricky part is with the Korg....

Love your work cimo!

Hahah that was my first thought and I didn't post it... my stupid memory :) ACSensorizer is midibox stuff and you can find goodies on our wiki/forums too... AudioCommander has done great work with this, it's a must-see for alternative controls.

Ahh cool :) Good luck with those projects BTW, feel free to post them in misc when it's sorted! Yeh essentially, the MBHP Burner module can be considered to be a type of Tait burner clone. There are various apps which can be used to control the burner from your PC, and that's where the spcifics lie,.. but they aren't really mbhp software or MIDIbox specific, they're just apps for PIC burning in general. As we know which apps work best with the MBHP burner hardware, those are a good choice to use to burn these chips if you can... But it's not a 'must', so if the other forums recommend some other software, and it works with the MBHP burner, thats great :)

I see where you guys are coming from now.. I'll try to explain in greater depth... What happens at the moment, is that each 100us, a timer triggers an interrupt, which causes the AIN handler to be run. This reads in 8 analog inputs (each of them a pin on the PIC chip) simultaneously... by using the multiplexers, this 8 inputs can be increased to 8x8=64 inputs, read 8 pins at a time. This reads pin 0 on all multiplexers, then pin 1..2..3.....7. If the values read have changed, then the AIN_NotifyChange hook in the application is called. The arguments passed to this function, tell us which pin has changed, and what value it is now. This is where you can deal with the new input, and process it in some way - in this case, comparing the value to a threshold, and sending a note-on message according to the pin number that has registered a change. If you wait until this point, you can continue to read the relevent data (the value of the keys that are held in, that you want to track for aftertouch) from the PIC's memory at a higher rate. This is a good idea, and I think this is what you're suggesting. The issue with this, is that the PIC and the OS, will still be having to read from the muxed AINs at the same rate as always, so you'll just be reading the result of the normal analog read from RAM more often, which won't actually get you any increase in resolution. If you optimise the mux driver, then you can have the relevant analog inputs actually scanned more often, which will give you better resolution for your aftertouch. Normally this would not really be so necessary, but as you will be writing a custom multiplexer to use more than 64 keys, it makes sense to do this, to get the best performance. I didn't want to confuse the above topic too much, but as I mentioned, the MIOS mux driver does already have some very similar optimisation in place, to what I have proposed here. It is optimised for human hands - it reads more frequently from the last two changed values (left hand, right hand!). This optimisation in itself may be enough.... Perhaps you'll want to monitor the last 10 (fingers) more heavily... I'm no pianist :-[ FYI, the difference in core32 when it comes out, assuming there are no changes (which is unlikely, but no promise, it is in prototyping after all) is that it has 12 analog inputs on the chip, so the 8 into 1 multiplexers can read 8x12 = 96 inputs. The analog inputs are also read using the DMA controller, so it happens in the background with minimal interruption to your app. it just starts the read, goes away and continues with your app, and when the read is done by the DMA controller automagicallyin hte background while your app runs, it calls a function to let you know. arjan you are probably familiar with callback schemes already so you know what I mean there. Guys who are used to MIOS8 will be impressed by this new feature :) As far as I am aware (TBH I haven't checked yet!) the MIOS32 AIN driver has the same 'last two pins' optimisation as MIOS8 does, so if you're considering holding off until mios32, perhaps that will be sufficient... perhaps not...To use one example you mentioned, if you are slowly releasing just one key while holding the others, perhaps this will be spot on. It depends how stable your hold on the other keys is :) Sorry the info is not highly specific, as I say I'm not much chop on keys (I'm a strings and skins guy myself) but I hope the tech info is helpful!

well switching between one or the other yeh ;) Well there isn't any MBHP software so to speak... There's MIOS, which only runs on PIC18F devices, and there are some apps for 16F88s and some older chips too. There is the MBHP (MIDIbox Hardware Platform) burner which is hardware as MBHP suggests, but it can use various applications to drive it to burn your chips. What are you trying to do exactly? Maybe we can give better advice if we have more direction :)

Welcome aboard nlate! That's more like 2 dollars, than cents, lovely. Way to make a grand entrance :)

Man you guys do seem to have some shoddy workers. At least I know that in you guys, the next generation of workers will have some pride in their work. Hang in there, mates :)

Or better yet you could use the super duper search I put on the wiki that searches for HD44780 *and* all of the known working compatible chips ;)

Err, maybe I'm missing something but that sounds kinda backwards...ie, won't work. The mux (and you DO need it, there are only so many AINs on the core, you can't run 76 keys worth of analog inputs direct to the core) will be running at a driver level and only once it has finished reading in all of the voltages for all of the keys will your application be notified of that read. So by the time you send MIDI, it's too late to change the mux behaviour. Besides, Why would you convert AIN X to Note Y and then use Note Y to adjust the behaviour of the mux and how it reads AIN X (and all the others)? why not just use the original input of AIN X ?

Sure is!

AC-Sim is really intended for algorithm testing and such, not really for CS stuff so much.... but you can always add functions for anything that's missing :)

Stupid computers. http://www.youtube.com/watch?v=kBVmfIUR1DA

Great find bosone :) Since this is one of those design concepts that just never dies, I am bringing that zip onsite :D db50ext.zip db50ext.zip

omg, an actual functional MB808! Whee :D (sorry don't see many of those!)

Welcome aboard arjan :) Interesting idea, but not too simple... The short answer is yes this could probably be done... With a fair deal of effort. Things that require consideration: You're probably going to need per-key calibration unless your sensors are really accurate You'll need to write a custom multiplexer driver that can address all of those keys, and it would probably make sense to optimise it to read from the keys which have reached a voltage you use as a threshold (as in, when the key is held in, track it's movement). That said, the MIOS AIN mux driver already has a similar optimisation (reads from AINs which have changed) and core32 supports 128 AINs. Perhaps that would be a platform worth waiting for (it'll be ready when it's ready, as they say...) Once you've got it working mechanically and electronically, then it's a matter of writing an app to deal with the voltages and convert them to the combined on/off and aftertouch messages. I hope you've got your experimenter's hat on :)

LOL I thought you lived in Melbourne? You may sayyyyy I'm a dreamerrrrr......

A battery is definitely a good option there :) Sorry, obviously I don't know the machine well...

That looks like it needs to go in the MIDIbox of the week subforum to me...........

It's funny the mix of thoughts I had upon watching this... On the one hand I see it as no big deal, a natural extension of commonplace technologies we have today, and an implementation of them which has been proposed by mannny people in the past - it's just that MIT has the funding/time to make it happen. On the other hand, I cannot help but look at these things and think to myself, shit, not that long ago the hottest personal computer I could get my hands on, was about 20kg heavy and had a monochrome green screen, and even if there had have been such interfaces to that machine, which there definitely weren't (the mouse was new back then) it would've taken several weeks to do what this does in the blink of an eye.... Kinda blows my mind and makes me yawn at the same time :D

The first thing I would do here is to confirm that there are no issues with ground loops in the audio signals, and that the PSU is working as it should... meaning, try a known-good PSU, and run the synth direct into your amp.

Yep, that works under Magic Blue Smoke Theory... Yaknow if you fry a component and Blue Smoke comes out, and you pack all the smoke particles back exactly how they were, it works again! Awesome :)

Hah that's fun :)