Max Romantschuk

I second Python for cross-platform apps. The problem is, though, that there's no definite MIDI-library for Python. There is a lot of stuff which works, but I have yet to find a cross-platform MIDI-lib which is also maintained. It might make sense to abstract the MIDI stuff in case you end up having to change libs in the future. Java seems a good option for cross-platform stuff (MIDI included) these days, but it's nowhere near as fun to program as Python is. In any case, this is a good place to start for Python MIDI and music stuff: http://wiki.python.org/moin/PythonInMusic

Maybe so. I have contacted Simple Machines with this suggestion. But it could be a long time before that change is implemented, if ever. Hopefully soon! :)

Yes, I had found the wiki entry already. :) I actually sent that link to Mike, seems it was news to him. Surprising though, but I'm hoping it means that he doesn't have any affected parts. Otherwise one would assume someone would have noticed by now...

I took a look at the SMF forum sources. The bad news is the form submission method in hard coded in the (rather convoluted) code. The good news is that it seems like there are only a few places where the actual search forms are. I should be able to do the needed modifications pretty quickly. I grepped the source tree for lines containing both method= and search2 (the search result action). These came up: max@tor:~/tmp.smf_forum$ grep -R "method=" * | grep search2 SSI.php: <form action="', $scripturl, '?action=search2" method="post" accept-charset="', $context['character_set'], '"> Themes/babylon/index.template.php: <form action="', $scripturl, '?action=search2" method="post" accept-charset="', $context['character_set'], '" style="margin: 0;"> Themes/default/PersonalMessage.template.php: <form action="', $scripturl, '?action=pm;sa=search2" method="post" accept-charset="', $context['character_set'], '" name="pmSearchForm"> Themes/default/index.template.php: <form action="', $scripturl, '?action=search2" method="post" accept-charset="', $context['character_set'], '" style="margin: 0;"> Themes/default/Search.template.php: <form action="', $scripturl, '?action=search2" method="post" accept-charset="', $context['character_set'], '" name="searchform" id="searchform"> Themes/default/Search.template.php: <form action="', $scripturl, '?action=search2" method="post" accept-charset="', $context['character_set'], '" style="margin: 0;"> I'm fairly sure that simply changing method="post" to method="get" should render all search forms to use HTTP GET parameters in the query string. Is there a develoment/staging instance of this forum where this could be tested? Testing on my own machine is sort of tricky as I'd have to set up Apache, PHP, and a suitable database, as well as populate it with data... :)

Couldn't all the forum search forms use HTTP GET instead of HTTP POST? This way you only have to do a search, and copy-paste the URL instead of having to know the query string variable names. Shouldn't be a huge change, right? (I can help out if need be. :) )

I checked with Mike about the EUSART bug. He said "til now nobody told me about problems with the PICs." One would assume someone had noticed any problems by now... ;) I'll probably be ordering the parts shortly, then I can dig deeper into the documentation 'til they arrive. :)

I guess the core of the problem is that I wouldn't know what to search for in the first place. Once I familiarize myself more with the terminology and environment I'll get better at avoiding the "stupid questions". Learning which terms to use when searching for things is always tricky in an experts' forum. (I'm an experienced programmer, so I share your frustration... ;) ) OK, that was indeed a key piece of information! :) I'll be sure to check!

Is there a really good reason to go for SmashTV and not Mike? http://www.mikes-elektronikseite.de/shop_englisch/index.htm I'm in Finland, so ordering inside the EU makes a lot of sense both in regards to delivery times as well as avoiding possible hassle with customs. I have a huge amount of poorly chosen hobbies... ;) I hope to have this project completed in say 1-2 years. Thinking I could do it faster would not be realistic... ;)

Well, the past ten years of programming experience had to be good for something, even if I haven't done any assembly programming... yet! ;) For me this is fortunately not an issue. Right now I'm just trying to clone the PG-300 for purely programming my Alpha Juno 1. Regarding the implementation, I had an idea on the workflow: Buttons and pots/slider for all parameters. When a parameter is changed that parameter shows up on the LCD along with the value. Next to the LCD a single encoder would be used to tweak the currently showing parameter. This way I could get the best of both worlds. :) I'd still be very grateful for confirmation that I could start experimenting with the 64 and 64E firmwares with a core, DIN and AIN? Also the choice of PIC still puzzles me. I'm sure the answers to all there questions are buried somewhere on Thorsten's site / the wiki / the forums, but with four small kids at home I can't spend huge amounts of time digging. ;)

Thanks for the info Sebo! I was surpised to be able to follow the code in the file, given that I usually work quite a few layers of abstraction up from the processor... ;) Could anyone please confirm or deny my earlier questions? I'm a bit of a learning by doing kind of guy, so I'd quite like to order some parts to play with... But obviously I'm not going to order anything until I know I can make it work! ;)

I saw this earlier through Make's blog or something, and I think it's a really cool project. You haven't updated the blog in a while, how are things going? One thing I'm thinking about though is durability, and secondly velocity sensitivity. Any thoughts on those? Velocity sensitivity basically requires two digital inputs and measuring the time between the two, right? (Given a physical key with the necessary outputs.) But does the core track events fast enough for that to be doable, or would every key need it's own circuit or something?

You make a good point. Perhaps it would make the most sense to get a core, LCD, 1 DIN and 1 AIN. This way I could experiment with pots, encoders, faders and buttons before making up my mind on a more specific design. Would I be able to play with both the 64 and 64E firmware with this setup? If I order the kits for these modules, and a PIC with a bootloader, is that all I need to do my experimenting, apart from power supply, buttons, pots, encoders, interfacing stuff like that? How do I choose which PIC? They all seem rather cheap, would a 18F4620 make sense? I understand it has more memory, which would translate into grater freedom if I eventually roll my own firmware?

OK, I've been doing some more research... I think the most sensible approach would be to start with a really simple setup, with a core, a DIN module, and an LCD. If I order the parts as kits from Mike's shop along with a PIC with the bootloader included that should enable me to get my bearings and do some experimentation before I decide on how to proceed. With a single DIN module I can try out playing with both buttons and encoders with the 64E firmware, right? I'm not sure if a version of the 64 or the 64E makes more sense really. In any case I'll start with a finished firmware before attempting to roll my own. Otherwise the learning curve will be too steep... Does this sound like a plan? I obviously need to check the part lists of the kits and get any extra components from somewhere else, but there's a pretty well stocked electronics store not far from here so basic components shouldn't be a problem. Any other huge things I've overlooked? :)

Hello everyone! I am a total newbie to advanced electronics projects, and the MIDIbox platform. I am, however a programmer by trade, and have extensive soldering skills (lots and lots of audio cables in my home studio). I came up with the idea of creating a programmer for my Roland Alpha Juno synth, which would essentially be a control surface outputting sysex messages. Basically I'm planning to create my own clone for the Roland PG-300: http://www.vintagesynth.com/roland/pgs.shtml#pg300 The Alpha Juno's sysex interface is very simple. Basic specs are here: http://www.vintagesynth.com/roland/sysex.shtml#ajuno From what I understand I could probably build a MIDIbox64 or MIDIbox64E and program it to do just this. I'd also like the final control surface to have dedicated encoders and/or buttons for every parameter. For parameters with only a few options or ON/OFF I'd like a button to cycle the options. For ranges encoders would be best, of course. Having a bunch of leds for the status of the parameters makes little sense, as the control surface is essentially stateless. Instead I think it would make more sense to have and LCD showing the parameter being edited at any given time. These are just some initial thoughts. I guess at this point I'd like some suggestions from the community on how to proceed. I can teach myself the necessary electronics knowledge and things like that, but the big questions are how to make appropriate hardware choices, and if I can use existing firmware or do I need to look into customizing my own? I'd like to thank everyone in advance for any useful information on how to get this project started! Hopefully I will get to finish it too, eventually... ;) EDIT: For anyone finding this though a search, there is a project thread here: http://www.midibox.org/forum/index.php/topic,12698.0.html