James-F wrote:

This is a nice idea BUT:
To see something you still have to connect a monitor to it, mouse and keyboard are also necessary to control the PI.
You have to be a PhD in Computer Science do the simplest things in Linux, steep learning curve is a gigantic understatement. 😐

Firstly, I'm new to the Raspberry Pi, and Linux as well. You can setup everything without touching the command line! I was very much positively surprised.

For the other point, see this as a proof of concept. There are lots of things you can do, for example a simple start-up script that sets everything up. But you can also write a program that talks to a little LCD display, have some buttons. So this can quickly develop into a proper little MIDI box.

I'm just scratching the surface here, but it's a good start 😀

brostenen wrote:

This might interrest someone. There is startup/shutdown scripts in this toturial.
Been looking at this, alongside other information, for creating my version of a cheap synth.

http://www.instructables.com/id/PiMiDi-A-Rasp … w-I-Learned-to/

That's it. To start FluidSynth and map the USB MIDI interface to it, only a 2 line script is needed.

James-F wrote:

You have to be a PhD in Computer Science do the simplest things in Linux, steep learning curve is a gigantic understatement.

Found the person that hasn't looked at Linux in the last 10 years 😊

Ampera wrote:

Yea I know that, but how is the relevant? Which CLI? Are you talking about bash, batch, what?

Does not matter.... I only said that CLI is like Dos command line on stroids.
You can do pretty much the same basic stuff. Linux can do a lot more, hence "on steroids".
You know... Set owner/group permissions and set up a complete server on linux.
Update and all that stuff. I know it depends on what you have installed.
You can just do so much more in Linux, compared to Dos.

RJDog wrote:

James-F wrote:

You have to be a PhD in Computer Science do the simplest things in Linux, steep learning curve is a gigantic understatement.

Found the person that hasn't looked at Linux in the last 10 years 😊

Hmmm.... I do not have a PhD in computer science, and I find Linux rather nice and sometimes easy to manage.
Shure it is a different story when setting up a server. Yet for the basic tasks such as installing stuff and update
the system, setting permissions and looking in config files. It is not that hard. It's just different.

PhilsComputerLab wrote:

That's it. To start FluidSynth and map the USB MIDI interface to it, only a 2 line script is needed.

Can you use it for you'r project?

brostenen wrote:

Does not matter.... I only said that CLI is like Dos command line on stroids. You can do pretty much the same basic stuff. Linux […]
Show full quote

Ampera wrote:

Yea I know that, but how is the relevant? Which CLI? Are you talking about bash, batch, what?

Does not matter.... I only said that CLI is like Dos command line on stroids.
You can do pretty much the same basic stuff. Linux can do a lot more, hence "on steroids".
You know... Set owner/group permissions and set up a complete server on linux.
Update and all that stuff. I know it depends on what you have installed.
You can just do so much more in Linux, compared to Dos.

Yea, so you mean the bash command interface. CLI is a generic term and refers to Batch(DOS) command interfaces as well as any other. Red isn't only for sports cars.

So today I tried my Orange Pi PC. Orange Pi is a Chinese board based around a Allwinner H3.

Installed Armbian and got everything up and running. But the music doesn't play smooth. It's like "skipping" sometimes and the timing can vary. I also encountered a few oddities when running Lakka. So yea, these Orange Pi boards are really cheap, but it seems the software support is far worse. With the Raspberry Pi everything just works it seems.

Ampera wrote:

brostenen wrote:

Does not matter.... I only said that CLI is like Dos command line on stroids. You can do pretty much the same basic stuff. Linux […]
Show full quote

Ampera wrote:

Yea I know that, but how is the relevant? Which CLI? Are you talking about bash, batch, what?

Does not matter.... I only said that CLI is like Dos command line on stroids.
You can do pretty much the same basic stuff. Linux can do a lot more, hence "on steroids".
You know... Set owner/group permissions and set up a complete server on linux.
Update and all that stuff. I know it depends on what you have installed.
You can just do so much more in Linux, compared to Dos.

Yea, so you mean the bash command interface. CLI is a generic term and refers to Batch(DOS) command interfaces as well as any other. Red isn't only for sports cars.

No... I am talking about every Command Line Interfaces in Linux.

Edit:
I was allways told, that in Linux and Unix, it is called CLI.
In Microsoft systems (Win and Dos) and also in Os/2 it is named command prompt.

So my quesion again. Is there something I have missed?

Tbh, I've found that the most common terminal implementation in linux (Used by Debian, Arch, Gentoo, etc. etc. based operating systems) is called Bash. it's usable in Windows by the Git implementation of it used for source control. In Windows, the system should really be called CP/M as that's where it came from, but it could be called DOS, as in the DOS systems taking after CP/M like PC, MS, and DR-DOS, but you could also call
it batch after the script files it can run.

Whatever you call it, CLI is a generic term, and Bash refers to Linux's terminal interface, while Batch refers to the CP/M derived interface.

Ampera wrote:

Tbh, I've found that the most common terminal implementation in linux (Used by Debian, Arch, Gentoo, etc. etc. based operating systems) is called Bash. it's usable in Windows by the Git implementation of it used for source control. In Windows, the system should really be called CP/M as that's where it came from, but it could be called DOS, as in the DOS systems taking after CP/M like PC, MS, and DR-DOS, but you could also call
it batch after the script files it can run.

Whatever you call it, CLI is a generic term, and Bash refers to Linux's terminal interface, while Batch refers to the CP/M derived interface.

Then I have been told wrong by the Unix teacher that I had, back in 1995. He told everyone, that CLI is used in the Unix world and everywere else, it was called command prompt. Both in CP/M world, IBM/MS world and so on. Yeah... The idea of drive letters and such, comes from CP/M.

DOS it self, does not come directly from CP/M, nor is it develloped from CP/M. It came from Q-Dos or 86-Dos. (Can't remember what name)
MS bought it from a small company called Seattle Computer Products. And modefied it for use on IBM's first PC.

There are many CLIs in Linux, the most common by far is bash (Bourne-again shell) but there's also csh, ash, tcsh etc.
Can we stop derailing this thread now? You don't need a PhD in CS to use the CLI in Linux. I did it very successfully since 1997 when I was a graduate student in biochemistry. The only CS I ever studied was on my home computer(s).

stamasd wrote:

Can we stop derailing this thread now?

I, for one, am very interested in hearing how MUNT performs on the Raspberry Pi in this configuration!

I, for one, am very interested in hearing how MUNT performs on the Raspberry Pi in this configuration!

This is an extremely nice xmas brake challenge, have all the parts needed, I'll get on to it 😀. Monkey Island 1 would be suitable for a demo, right?

You can start with a prebuilt image or follow the instructions to install it yourself:
Emulating MT-32 on an RPi2

gdjacobs wrote:

You can start with a prebuilt image or follow the instructions to install it yourself:
Emulating MT-32 on an RPi2

That will come in handy. At this stage I don't understand most of the commands, but nothing a bit of researching and reading can't solve 😀

But I wonder, how do you then use Munt? Run mt32d and then connect the USB MIDI interface with Munt?

What would be nice, rather than everyone having to compile it themselves, is there a way to package the compiled program? So to make it easier for others to use?

apt-get munt-pi or something like that 🤣

Just realised I haven't actually said anything about the actual thing you did.

It's really cool. I want to do it with a modern PC so I can load massive soundfonts, I could use anything up to 14GB of samples on my main rig (14GB for samples, 2GB for Windows 7 = 16GB RAM) using something like CoolSoft's VirtualMidiSynth, a USB MIDI interface, and a line out to line in mixing loop for something like my AWE32.

PhilsComputerLab wrote:

That will come in handy. At this stage I don't understand most of the commands, but nothing a bit of researching and reading can […]
Show full quote

gdjacobs wrote:

You can start with a prebuilt image or follow the instructions to install it yourself:
Emulating MT-32 on an RPi2

That will come in handy. At this stage I don't understand most of the commands, but nothing a bit of researching and reading can't solve 😀

But I wonder, how do you then use Munt? Run mt32d and then connect the USB MIDI interface with Munt?

What would be nice, rather than everyone having to compile it themselves, is there a way to package the compiled program? So to make it easier for others to use?

apt-get munt-pi or something like that 🤣

checkinstall is probably the easiest way to create a .deb file for debian dpkg but i have not used it in a few years...

as for doing munt, Id run mt32d on startup, you'd need a fixed configuration so the name of the device doesnt change all the time and use patchage/qjackctrl/etc to create the midi device routing and thats it.

I probably won't bother with a deb package, at least right now, for two reasons:
ARMv7 optimizations are very hardware specific. Munt would have to be built differently for Cortex A7, A8, A9, etc.
I can just provide a full image for the Pi, as the hardware is the same.

gdjacobs wrote:

I probably won't bother with a deb package, at least right now, for two reasons:
ARMv7 optimizations are very hardware specific. Munt would have to be built differently for Cortex A7, A8, A9, etc.
I can just provide a full image for the Pi, as the hardware is the same.

But isn't a full image even more specific?

I see it as two extremes, either compile it yourself, or use your image. There could be something "in the middle" that's easier to use and makes this project more accessible to a wider range of users.

BloodyCactus wrote:

checkinstall is probably the easiest way to create a .deb file for debian dpkg but i have not used it in a few years...

as for doing munt, Id run mt32d on startup, you'd need a fixed configuration so the name of the device doesnt change all the time and use patchage/qjackctrl/etc to create the midi device routing and thats it.

Ok thanks for the pointers!

Ampera wrote:

Just realised I haven't actually said anything about the actual thing you did.

It's really cool. I want to do it with a modern PC so I can load massive soundfonts, I could use anything up to 14GB of samples on my main rig (14GB for samples, 2GB for Windows 7 = 16GB RAM) using something like CoolSoft's VirtualMidiSynth, a USB MIDI interface, and a line out to line in mixing loop for something like my AWE32.

Be sure to check out: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

It can do all of that, without having to use any other tools 😀

Phil:

Was those scripts in the link to the midi-diy that I mentioned, at any use?

brostenen wrote:

Phil:

Was those scripts in the link to the midi-diy that I mentioned, at any use?

Hmm I don't see how these are related to be honest...

PhilsComputerLab wrote:

gdjacobs wrote:

I probably won't bother with a deb package, at least right now, for two reasons:
ARMv7 optimizations are very hardware specific. Munt would have to be built differently for Cortex A7, A8, A9, etc.
I can just provide a full image for the Pi, as the hardware is the same.

But isn't a full image even more specific?

I see it as two extremes, either compile it yourself, or use your image. There could be something "in the middle" that's easier to use and makes this project more accessible to a wider range of users.

You're not wrong, having a single package would be very end user convenient. Unfortunately, providing good performance requires the MT32 library to be built for ARM's different execution backends. Perhaps with some funky scripting, a single package could install optimized binaries depending on which CPU is detected, but that would again be quite a bit of work. The other way to organize it would be different packages all providing an MT32 meta package which is user selected based on the code path they require. A similar amount of work, just laid out a bit differently differently.

If I were to go build a DEB, I'd feel compelled to package the software in such a way. My other commitments are such that this isn't really an option for the next couple of years.

I can certainly TAR up the source tree with all compiled objects for those interested, but fetching and building MUNT from source remains the most reliable way to have the latest version.