Jump to content
arcadeshopper

TIPI enabled software listing

Recommended Posts

11 hours ago, wierd_w said:

You just write midi messages to the midi device in the device tree like a file.  You can send such messages with echo.  Since you give telnet/console already, it should be doable right now.

 

well, yes, you can configure fluidsynth to take textual representations of commands from a socket. So then you could just use the TCP feature of TIPI to control it... but song representation this way would eat up resources on something like a 4A quickly... good enough for proof of concept, but "noteon 1 66 100\r" form commands are expensive... 18 bytes instead of 4 if it were MIDI format.  fluidsynth talks about ports a lot, but they seem like midi-ports, not TCP ports... so I don't know how you get MIDI format data directly to it.  But, I'll leave that as an experiment for you all.  Surely there is some way with Jack or ALSA tools to do so. 

 

[email protected]

Share this post


Link to post
Share on other sites

Silly man, the Pi has all kinds of things you can use to alleviate this.

 

Take for instance--

 

"mkdir /tmp/midicache && mount -t tmpfs /tmp/midicache"

"echo "(long screed of midi messages that comprise a song)" > /tmp/midicache/somesong.dat"

"echo "(player handler shell script that monitors for input over TCP/UDP to control midi playback here)" /tmp/midicache/handler.sh && chmod +x /tmp/midicache/midihandler.sh"

"daemonize /tmp/midicache/midihandler.sh"

 

Then you just send whatever bytecode messages over your listen port you want, to syntactically say "Play song 1 from 00:00 to 01:00 now, then loop from 01:00 to 02:50"

 

The pi just does it when you send that small command message.

 

It stores data in the pi's memory (tmpfs mount), in a non-persistent fashion, in order to "write once, play many times".

 

 

 

For the innards or "midihandler.sh", so that it can listen for messages over a TCP port, there are a great many implementations out there. Stack exchange has you covered in most of them.

 

https://unix.stackexchange.com/questions/314550/how-to-set-a-script-to-execute-when-a-port-receives-a-message

 

Writing data to the appropriate midi device in the device tree from a specific file is trivial-- One could use dd, for instance, since it allows you to specify an amount of the source file to skip, AND a rate at which to write.

 

eg,

 

dd if=/mnt/midicache/somesong.dat of=/dev/somemidi0 skip=[some number of blocks to skip on the input before writing] count=[some number of blocks to write] bs=[number of bytes to read/write per block]

 

wrapped up in an appropriately variable-ized for loop, that takes data from the tcp listening port, and populates the appropriate areas.

 

 

 

Writing to the midi device this way is fully kosher.

https://ccrma.stanford.edu/~craig/articles/linuxmidi/output/section1.html

 

Fluidsynth and pals create a midi device that operates the same way as an external synthesizer, which means you can write messages to it this way. The midiport is the number at the end of the device file's filename.

 

That is how you send it an arbitrary midi command.  If you want to send an arbitrary midi command instead of caching them all and then using simple instructions to control playback, then you just use "midihandler.sh" to wrap the exchanged message, and echo it to the appropriate device, like I initially suggested.

 

 

Edited by wierd_w

Share this post


Link to post
Share on other sites

Alternatively, if you dont want to use OSS (which that write method implies), you can use an alsa utility instead.

 

https://www.systutorials.com/docs/linux/man/1-amidi/

 

As you see, it does raw bytecode messages, to a specified midi port. (Eg, "fluidsynth:0" etc.)

 

You would just variableize it appropriately with your shell listening daemon, so that you can send it bytecode over a tcp port instead.

 

 

In addition to fluidsynth, there is also timidity++, and munt.

 

Since you seem to like MT32 as an instrument, you might be especially interested in munt, however there are niggly license issues there. (Needs roland's rom files from the MT32 to do its thing.)

Edited by wierd_w

Share this post


Link to post
Share on other sites
Alternatively, if you dont want to use OSS (which that write method implies), you can use an alsa utility instead.
 
https://www.systutorials.com/docs/linux/man/1-amidi/
 
As you see, it does raw bytecode messages, to a specified midi port. (Eg, "fluidsynth:0" etc.)
 
You would just variableize it appropriately with your shell listening daemon, so that you can send it bytecode over a tcp port instead.
 
 
In addition to fluidsynth, there is also timidity++, and munt.
 
Since you seem to like MT32 as an instrument, you might be especially interested in munt, however there are niggly license issues there. (Needs roland's rom files from the MT32 to do its thing.)
This sounds like a Dev thread

Sent from my LM-G820 using Tapatalk

Share this post


Link to post
Share on other sites

JediMatt kinda IS the developer of the TiPI...  

 

This is a pretty simple thing to get the Pi in a TiPI to do... You just need the appropriate pokes in the Pi's config.txt (he does maintain the tipi's firmware for the pi), and the right circuitry dangled off the right gpios on the pi.  

 

Like I initially pointed out-- once the pi is wired up to the speaker leads on the sidecar bus, the existing TiPI command set is sufficient to send the messages to the pi. 

 

All the pi needs is the right set of already existing linux utils, and a generic wrapper script.

 

 

I was just curious if anyone had already done this or not.  Apparently not.

Share this post


Link to post
Share on other sites
JediMatt kinda IS the developer of the TiPI...  
 
This is a pretty simple thing to get the Pi in a TiPI to do... You just need the appropriate pokes in the Pi's config.txt (he does maintain the tipi's firmware for the pi), and the right circuitry dangled off the right gpios on the pi.  
 
Like I initially pointed out-- once the pi is wired up to the speaker leads on the sidecar bus, the existing TiPI command set is sufficient to send the messages to the pi. 
 
All the pi needs is the right set of already existing linux utils, and a generic wrapper script.
 
 
I was just curious if anyone had already done this or not.  Apparently not.
Yes my point is that this is the TIPI software listing thread.. you should post this info in the TIPI Dev thread and go ahead and develop this. The platform is ripe for new Dev. Go for it.. I look forward to the announcement here in the software thread when it exists.

Sent from my LM-G820 using Tapatalk

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...