Turning a micro computer system into MIDI device

[kortezzzz]

WOW guys, thank you so much for investing your time on these wonderful comments.

After all, looks like we do have some actual solutions to make "hardware a like" FS app based midi controller.
The "spanish" MIDI-TO-MIDI looks like everything I'll ever need:

1) Its dedicated midi device
2) It streams midi data splited to channels
3) It recognized by both computers, the "transmitter" and the "receiver"
4) Its compact and easy to seed into almost any configuration

Now, the biggest question would be: is it really does what it says without any hidden limitations?

@strangeChild,
Any idea who sell this thing?

@oddson,
Your solution looks quite easy to make and cheap. The only question would be the driver itself. If we could program the driver to show a the name we desire, it would be even greater (like "oddson midi controller").

Well my plan is to use a cheap windows tablet with windows embedded installed on it, and as you fire it up, the FS software would load itself automatically. The tablet's first usb input would allow connecting midi gear while the second usb would function as "midi out" by default and would be connected to other computers or midi based sound modules. The FS app would be a kinda virtual control panel and would be armed with programmable midi sequencer.

I believe it wouldn't be such a hard technical challenge to build this hack and it would finally show FS's actual
benefits as a musical tools production software.

Thanks again guys. Hope one of those solutions would do the trick.

[strangeChild]

I couldn't get my tablet's browser to translate the page... There's a contact page, try that.

When you say your plan is a Windows tablet... not sure how that would work if it a usb device instead of a host.

The external problem we've been talking about goes away, but I don't know if Flowstone would be able to connect to it for outbound midi. If so, there's the problem sorted.

[kortezzzz]

not sure how that would work if it a usb device instead of a host

It possible. As long as FS detects midi out device, it allows you to stream midi through it. Since the usb-to-usb is a dedicated midi device, FS would stream to it. From that point, the usb-to-usb midi device should do the trick and create a simple midi loppback, just like the virtual midi cable-

http://www.tobias-erichsen.de/software/loopmidi.html

I've already used a virtual midi cable in one of my projects and the results were great, so that's why I decided to
to try the same method with a real cable. No doubt this setup would share midi with the outside world and moreover, the communication would be bi-directional as well; you would be able to receive a feedback from the target computer.

[Attic]

@Kortezzzz Would you keep us in the loop on how that machine holds up cpu wise when you get further into the project. I'm still looking for a good candidate for some of my project's so it would be helpful to know what other FS user's find.

[kortezzzz]

@Attic

Its depends on your project. Forget about using it with sample projects, synths or any audio. It's CPU would handle nicely some Ruby based midi sequencer clocks, but would choke almost instantly with audio streams.
I've ordered the newest model which has slightly better performance compared to the z3735 CPU, so I'll have to wait
and see.

http://www.aliexpress.com/item/Latest-PIPO-X9-Mini-PC-Windows-10-Android-4-4-Dual-OS-Intel-Z3736F-Quad-Core/32475233880.html?spm=2114.01020208.3.36.dwsQYI&ws_ab_test=searchweb201556_7_79_78_77_80,searchweb201644_5,searchweb201560_7


I'm also not sure that those machines can run correctly with windows embedded version since they are provided with their own special Windows 10 edition (that contains the matching drivers, built in). I'll have to test it first.

[oddson]

@oddson,
Your solution looks quite easy to make and cheap. The only question would be the driver itself. If we could program the driver to show a the name we desire, it would be even greater (like "oddson midi controller")...

I think writing the sketch to run this (same sketch on both Teensys) will be even easier to write than I suggested above.

Some forum postings at PJRC lead me to believe you have to handle each type of MIDI message separately. I've since determined that's not the case (or at least I'm fairly confident a single MIDI.send command can handle all MIDI that comes in byte triplets).

If so, for the main loop all that's needed to do everything except deal with SysEx would look something like this:

Code: Select all

void loop() {
// first read...
  if (MIDI.read() && type && MIDI.getType() < SystemExclusive) {
    type = MIDI.getType();
    d1 = MIDI.getData1();
    d2 = MIDI.getData2();
    channel = MIDI.getChannel();
// ...and then send...repeat
    MIDI.send(type,d1,d2,channel);
  }
}

SysEx would need some consideration because the data triplet structure is not used for SysEx so you'd need to handle message where getType retured SystemExclusive (a constant = 7). But this would not greatly complicate things.

I'll give it a try once I have some LCs to play with (I'm sure I"ll find a use for them after).

[oddson]

...If we could program the driver to show a the name we desire...

Currently you have to manually replace the name that displays to the host in a supporting file and it will apply to all MIDI projects you compile until you change that text. It's not really hard but it's a bit inconvenient. Paul says it's on the list of potential improvements but not high up that list.

[kortezzzz]

I'll give it a try once I have some LCs to play with (I'm sure I"ll find a use for them after)

Currently you have to manually replace the name that displays to the host in a supporting file and it will apply to all MIDI projects you compile until you change that text. It's not really hard but it's a bit inconvenient. Paul says it's on the list of potential improvements but not high up that list.

Great oddson, Thanks for the info. It looks promising, but right now, the "spanish" stuff looks more actual for testing since its PRO product and ready for use.

One of the problems in this project I can predict would be sending the main packed midi signals (status, channel, data1, data2) through FS's midi output (after they have been created by the Ruby code) to the midi device together with pitchband and the mode-wheel commands. I mentioned that streaming midi event (notes, pitchband, mode-wheel) through a Ruby based midi sequencer cause the pitchband and modewheel commands to disappear. If you try to connect your midi hardware straight to project's main midi output with an additional input link (to capture the pitchband signals), it causes errors and freezes and the midi session doesn't reach to it's destination correctly via the virtual midi cable.

Any chance there is a kinda ruby code fix that may combine both pitchband and main midi event to one packed midi stream that would work correctly?

[strangeChild]

... I mentioned that streaming midi event (notes, pitchband, mode-wheel) through a Ruby based midi sequencer cause the pitchband and modewheel commands to disappear. If you try to connect your midi hardware straight to project's main midi output with an additional input link (to capture the pitchband signals), it causes errors and freezes and the midi session doesn't reach to it's destination correctly via the virtual midi cable.

This doesn't sound right. PB and mod wheel are just more three-byte messages. Where are the details on this?

[EDIT] I think I get it... sounds like your Ruby code is not passing the MIDI it's not handling... it's roughly the same thing oddson's code above does... you just have to pass the parameters along trough the same output channel as the ones you're manipulating. [/EDIT]

[kortezzzz]

I'm not sure I understand what you mean. If you have any idea how to actually seed oddson's code properly in the ruby code, would be great if you could show it with a schematic.

Attaching a small example schematic that uses a ruby code to split the midi keyboard into 2 zones and passes midi notes as long as they are greater then the threshold point that determined by the knob. this schematic contains the problem in it: The recent setup doesn't capture the pitchband signals because for some reason, the ruby code "kills" the pitchband massages and sent only the channel\note\velocity parameters . If you try to add a separate midi input that should capture only the pitchband and connect it in parallel, it crashes. Any ideas how to fix?

Edit:

Sorry, attached a wrong example schematic. Now uploaded the right one.