Sheepdoll's postbag.

Tell us about the cool things you've recently got
User avatar
sheepdoll
Posts: 16
Joined: Wed Mar 27, 2019 12:42 am
OS: MacOS,Linux
IDE: Arduino,Eclipse
Core: STM official, HAL
Board: Nucleo, discovery
Contact:

progress and stuff

Post by sheepdoll » Mon Aug 26, 2019 7:17 am

I found some useful tutorials on You Tube. By someone called MYaqoobEmbedded. Usually uploads a new one on Sundays, has not added much this summer, but the ones online are somewhat useful. These cover the basics such as serial coms using a UART bridge.

There are drivers for MIDI over Serial USB using the FTDI bridge found on many Arduino and clones. Something I considered before moving code to the Arduino Leonardo, which works great. The Leonardo works as a MIDI to RS485 bridge which the system takes.

I have been converting the m68K assembly to C code. Sort of cheating writing it in a text editor, pure C one big file with no header files. Only the ncurses lib is linked. That way I can search and define all the memory structures as I add the functionality. Since it is pure C runs on a mac or on a Raspberry Pi. Will probably need to section it to move to an IDE.

The newer pipe organ code uses UDP/IP. I have been using wireshark to see how this works. Like the RS485 twisted pair everything is done in broadcast mode. No sockets. I got a bunch of PHY modules. It is fairly simple to set these up. I was able to fix the MYaqoobEmbedded examples from a number of years back that uses the simple RS232 type PHY. I also got the direct module working with one of my Nucleo boards and the demo code I found online. One does have to cut traces and disable things. Make choices as to what one needs such as removing the physical support for Direct USB on the 429i discovery in favor of the display, memory and external Ethernet PHY. This leaves the serial ports free for the back channel codes, such as diagnostics, or playback and record.

In practice MIDI over the wire is way to slow for a Pipe organ, Which can contain 1000s of pipes. MIDI over USB or MIDI over Ethernet does allow one to block buffer the data. MIDI can be used to read keyboards. There are also soft synths such as Fluid Synth which can do simple ranks. Programs like jOrgan can take standard MIDI input and actually come close to imitating a pipe organ. Or a recording of a pipe organ as every note can be sampled. There are other commercial programs which do this too.

Some systems even mix sampled sounds and real pipe sounds.

Andy2No
Posts: 27
Joined: Wed Aug 21, 2019 1:59 pm
IDE: Arduino 1.8.9 & 1.8.3
Core: STM official, MightyCore

Re: Sheepdoll's postbag.

Post by Andy2No » Mon Aug 26, 2019 10:25 pm

I have wondered what protocol gets used to connect a remote organ console to a large pipe organ. I guess it could be different for each manufacturer though, or even for different organs made by the same one.

If I was designing it, I'd be tempted to still go with MIDI, but increase the baud rate and use multiple circuits in parallel - and maybe just use thicker wires than a normal MIDI cable. I guess there are better ways, though.

Organ simulators that could be run on something like a Nucleo or Discovery board, with, say, a Core M4 MCU - or even a few of those used in parallel, to make the different registers would be interesting to play with.

Organs can be done pretty well with just looped samples, but I'm not interested in making something to do that. I already own some Roland hardware, probably from the 90s, that does that sort of thing about as well as can be expected.

I started looking at some simple physical modelling projects... I'm not really sure if the Karplus Strong algorithm counts, because it's more like a trick than a real physical model, but that's one of them. That does a very idealised version of a travelling wave simulation, using a circular buffer, and "filtering" that's just done by averaging two samples together, and putting the result back into the buffer.

I haven't got past the point of just getting someone else's project built and making a few changes for usability, yet.

I like the idea of using an FPGA to simulate an instrument, somehow (maybe fed data by an STM32), but I know very little about them. I found one example of the Karplus Strong algorithm done on one of those, but the source code hasn't all been shared, so I'm not sure that helps me much.

User avatar
sheepdoll
Posts: 16
Joined: Wed Mar 27, 2019 12:42 am
OS: MacOS,Linux
IDE: Arduino,Eclipse
Core: STM official, HAL
Board: Nucleo, discovery
Contact:

Pipe organ protocols

Post by sheepdoll » Tue Aug 27, 2019 4:45 am

Most organs have an electronic interface on them which is called a relay. These date back to the late 1800s and were developed by Robert Hope-Jones. (His brother Frank also did amazing things too.) They worked with early telephone switches and accurate clocks. There is basically a telephone switch inside the organ.

Before electricity, mechanical/pneumatic systems were used. These date back 2000 years to the Anchent Greeks and Romans. We have pictures and a few surviving things. By the middle ages such instruments using roller levers called trackers were the most complicated things man built. Such is a subject unto itself.

As for the protocols used in modern systems, they are proprietary. There are about half a dozen systems. Which are more custom than not. The big players are Uniflex for theater organs and Peterson for church organs. There are other systems such as Emutek and Opus-2. Most of these are done by a guy in the gararage. Some of these guys are in their 80s or 90s. Often or not the wife winds up with the IP.

On the software side, there is Hauptwerk, which is proprietary. MidiTzer (which was the first) and jOrgan, (Java virtual organ) which is open sourced and java based. These talk MIDI to the soundblaster card protocols.

There is only one electronic organ manufacture left. which is Allen. They use sample loops.

Most introductory electronics courses at the college level have the students scan a keyboard to midi. There are hundred if not thousands of examples online. The best solutions use a shift register such as the 74HC165 or the 74HC595. (the 74HC164 can also be used.) If one uses a shift register such as the '595 the signals can be memory mapped back through the A2D input. The reason for using the HC is so that a resistor current limiter can be used to trip the internal diode. The system inputs need to handle a nominal 12Volts which is usually 13.5 unregulated. There can be lots of amps behind it so usually there is 100K into the pin and a 10K pull up or pull down. This forms a sort of current limiting voltage divider.

The conversion between the shift register and event code, like MIDI is simply an XOR against a second buffer. A simple Arduino can do this and have plenty of cycles and other resources left over.

On the sound output side as noted above, pretty much everything is based on the soundblaster card. I think the maker was called creative. They used the Rolland sample loops for the default general midi. These are called soundfonts. There is a good open source player called Fluidsynth, which can interpret these sound fonts as a MIDI device on all the major operating systems. In the *nix world there is a rather good editor called polyphone. I forget what the Window$ sound font editor is called. The cheaper fonts are synthesized.

The soundblaster cards were ASIC based, so building a FPGA player would be pretty much re-making the wheel.

I once built 300 wavefile players which used the Tiny85 Avr. this 8 pin processor is comparable to an early Apple][. It should be possible to load a bunch of samples onto a many gigabyte SD card that drives the PWM. One could even have one sample per chip connected to say a small greeting card speaker. This way the soundfield would be spread out like the actual rank, rather than setting the tone with a pan pot. Most organs use a diatonic layout, which splits the octave into even and odd notes. This helps prevent certain harmonics which can dampen or re-enforce some of the effects. I sort of put this project on hold once I started using jOrgan and Fluidsynth, which will run on a Pi. On the mac I just take the output via SPDIF into some Rolland monitors, which have Toslink plugs.

Uniflex mentioned above evolved out of a system from the 1980s and 1990s called Devtronix. These were marketed by a guy named Ray Devault. He has been dead like 30 years or more, so the hardware is free for anyone to use. The lastest code however remains proprietary. The 1990s code was based on 68000. I was lucky enough to get some of the source from the late maintainer before he passed away. This was all based on custom hardware.

When Emutek stopped answering the phone, and took the website offline, I reversed engineered that too. This was to add features to the system. There were also a set of custom tools that came out of Austraila for the Capri organ. I converted these to Postscript, which surprisingly makes a rather good MIDI scripting tool. One can parse the data to show as a piano roll view, or even as sheet music notation, using a text based MIDI tool called ABC(MIDI) There are some useful programes called MIDItoABC and ABCtoMIDI when combined with ABCtoPs (Or ABCtoPDF) It makes it easy to convert the different formats. Now I am able to move between Uniflex and Emutek.

The jOrgan can then be used to play the rendered tracks. The jOrgan can also be used with a USB Midi interface to play notes direct from any MIDI keyboard. JOrgan is fairly clever, It ignores the channel numbers (other than the drum channel) It uses these to load and unload the soundfonts, allocating the voices dynamically to increase the polyiphony.

Other systems such as Allen and Hauptwerk use NRPN (non registered midi parameters) to control the stop tabs. These are fairly well documented in the manuals. Some of the early systems, simply used one of the channels to represent stops as note on off events. Hauptwerk uses a SQL database for the internal buffering.

Andy2No
Posts: 27
Joined: Wed Aug 21, 2019 1:59 pm
IDE: Arduino 1.8.9 & 1.8.3
Core: STM official, MightyCore

Re: Sheepdoll's postbag.

Post by Andy2No » Tue Aug 27, 2019 2:54 pm

That's interesting that they use SoundBlaster cards.

I wasn't thinking of recreating one on an FPGA, but to me, the interesting part of those boards is the FM synthesis, not the sample playback. Someone has implemented the OPL3 FM chip on an FPGA (from the later SoundBlasters). I wondered why they'd do that when it's still possible to buy the chip, but I guess it's old stocks, not something that's still produced.

One good reason is that there will always be FPGAs with more gates, so there might be room for more than one on the same chip, and some extra logic to tie them together in a useful way. Presumably, to build a SoundBlaster based organ, people have to scour eBay for surviving boards. If there was an open source FPGA version of one available, they could make as many as they wanted.

Also, ASICs are for manufacturers, not the likes of us. To make something similar as a hobby project, an FPGA would be the only practical way. Once you have a working design, you can improve on it, of course, just like if you have the source code to do something in software.

Post Reply