The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
So I have a grandiose, long term plan for myself, and I need some answers, information and direction for it to come into existence. Unless if fails a reality check, of course.
The reason for this project is the lack of support in the music industry for people, like me, that still has a lot of MIDI equipment, i.e. musical instrument (and other devices) with a MIDI interface (http://en.wikipedia....gital_Interface) built-in. There are nearly no large scale interfaces available anymore.
The project... the thru ports will be hardware through, i.e. they will not be involved in software (maybe a switch on the SB to turn thru on/off). The inputs/outputs will participate in a software "patchbay" (routing) scheme that I was counting on a SD card for one or more matrix configuration file(s).
I am not super "sure" of myself when it comes to the hardware, hence the questions, but I am not really concerned about the programming aspect. So the questions then:
I would like to use the Netduino Go (NG) to realize the project, with possibly up to eight (8) Shield Base (SB) units, but will start with one, of course. How many SB units will be possible to use on one NG?
The SB has four (4) UARTs, correct? Would I be able to cram four MIDI (in, out and thru) interface (http://www.midi.org/...electrispec.php) onto one SB, and use them? It seems it should be possible, but since there are other factors (currently unknown to me), and I am new to Netduino, I need to ask.
As for serial communication and the GoBus part, how is buffering on the serial virtualization done, or is it not? Maybe I am not asking correctly here, sorry. I ask about this because MIDI is relatively slow (31.25 kbaud) and tends to "fill up" when active in larger musical arrangement. Also, with the distributed nature of Go, it would seem like a good idea to buffer bytes "locally" on the SB until the NG host is ready to receive.
Anyways, for now, these are some of the questions I am seeking answers to. I apologize for not having ready the available posts and docs yet, but will when I get time.
I am not a MIDI expert, but I am afraid software routing implemented in .NET Micro Framework would not work very well due to the latency caused by slow (interpreted) execution of the manged code.
How about hardware routing, i.e. some kind of switch matrix, which would be controlled by Netduino?
Thank you both for replying. I appreciate the responses!
I am aware of the slow progress of NG (I've tried to read up on stuff in the forum). If things do not turn out, I will follow your advice Olaf and use the N+2, which I also already have and am using for learning purposes. I created a web server already, which isn't really that difficult, and then I also found out that the System.Http assembly was available, making such matters even easier!
I might think about doing multiple N+2 devices instead too. So is it possible to use the four UARTs for 4 MIDI interfaces (basically serial com in/out at 31.25 kbaud) at the same time?
There is also something called RTP-MIDI (http://en.wikipedia.org/wiki/RTP_MIDI) which is the standard MIDI messages (2-3 bytes each pretty much) communicated over Ethernet, which would be interesting too. I have not researched the protocol, so I am unfamiliar with it. I could also just transmit plain MIDI over Ethernet or some simple wrapper to spice things up a bit.
CW2, even though MIDI is so slow (in comparison to modern stuff anyways, I mean MIDI is as slow as an old modem) there could be problem with Managed code?
CW2, even though MIDI is so slow (in comparison to modern stuff anyways, I mean MIDI is as slow as an old modem) there could be problem with Managed code?
You should perform some tests to see how fast the serial communication routing in managed code really is. In the current version of .NET Micro Framework the managed code is interpreted, which means the execution is orders of magnitude slower than "native" code - think Basic interpreter vs. C/C++ compiler. I guess raw reading from one serial port and writing to another would not be significant slowdown, but it does take some time, and if you want to do some more processing (e.g. checking for whole messages, real-time clock synchronization etc.) the time will add up and the latency increases. While the MIDI transmission is not really that fast, latency in audio signal is something people can notice - so you should probably make some tests to see how much latency is introduced in your system, especially when routing the same input through multiple paths with different number of software nodes, if that is functionality you want to have at the end. A millisecond here or there should not be a problem, but tens of milliseconds could be noticeable (especially when you can hear the original sound). Another problem with audio processing is jitter - how much the latency varies. .NET Micro Framework is not real-time operating system, so there are no timing guarantees, interrupts are queued, the execution of managed code can be interrupted at any time for any reason, for example by garbage collecting. You'd have to program carefully to minimize such events.
Yeah CW2, I can see what you are saying. Fortunately, in MIDI there is not audio at all. However, I did build a breadboard MIDI interface this past Sunday and it worked great. I connected this old MIDI keyboard to it and routed it to a synthesizer I have and voila!
My next endeavor will be to try four of these interfaces and run a MIDI sequencer (Cubase) to all four of them, and I will add some code to route messages from 1 in > 2 out, 2 in > 3 out, and so on, just for test. This way I can load something from a heavier music arrangement to see if things will choke.
Thanks for you input, I really do appreciate any help I can get.
I am also looking into "I2C" (never used it before), and if you know of anything I should know of, please do tell!!!
(This has nothing to do with the MIDI project. Well, at least not that I know of.)
No, Nevyn, I hadn't until now, thanks a lot for sharing!
Pete Brown was one of the presenters at Build 2014 with the new MIDI API (WindowsPreview) for Windows RT. I am eternally grateful for his contributions on this front. MIDI is yet another example of the lame-struck (read business deadlocks due to ownership complex) times we live in. It's 2014 and there is still no real viable alternative to MIDI in terms of musical equipment and interoperability between them.
For computers and music, sure, there are a few options, but they are only so popular and availability is generally limited or too complex. Besides, for computers there is less need. It's nearly 30 years old, slow and for our times it's "too simple". But man, if it isn't the one thing that keeps going like the energizer bunny. That's the other thing with newer "MIDI" avenues, they always seem overly complex.
Anyways, this is why I am so interested in a project like this one I am working on.
Feel free to use any of that source code if it's helpful to you. It's all on Codeplex. I'll likely add a branch for Galileo as well.
Routing and filtering really need to be done in native code. When I tested things like MIDI clock (which runs at 24ppqn) netmf wasn't up to the task, so not good for routing or real sequencers.
I built a MIDI thru box some time ago with the intention of adding filtering and monitoring in netmf, but perf was a blocker.
My main MIDI interface now is a MOTU Express 64. It gives you 8 ins and 8 outs. You can also add more than one to a system. I also wouldn't say MIDI is being ignored out here, especially not with the resurgence of analog synthesizers with MIDI added, and with th popularity of stand alone sequencers like Elektron boxes and Akai MPC.
On the plus side: In Steve's IoT session at Build, we committed to improving perf in NETMF. Not sure what that means yet, or if it will help here, but I'm hopeful
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
I didn't mean that MIDI is being ignored at all, on the contrary, it's actually the one savior for hardware devices. (I was referring to a replacement.)
I have a lot of equipment that I've gathered over the years (don't have a heart to part with most of them). I use a Steinberg Midex8 myself. This is not quite enough, so I use a number of older (real old) devices to help out, a MIDI patchbay MSB 16/20 and a dial router MSB-1 in particular (both by JLCooper). Those are crutches at best tough, but they work, and I am used to them.
I was aiming to construct sort of a modular (computer) interface (rather like your Gadgeteer/GO solution in the other thread, actually) where they would be reported to the OS so that when ports are added they become available in, e.g. Cubase.
Sounds like a cool idea. I'll work on this project again in the fall, and am happy to collaborate on the software.
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
Answered
