Fatar TP/8 to midi (8x8 matrix with velocity)

Status
Not open for further replies.

el_rico

Member
Hello,

I plan to build a 3 keyboards console for a virtual pipe organ (I'm not a player myself), using 3 Fatar TP/8 keyboards and Teensy to "midify" them. It seems that I'm not the first one (great!), and it has already been mentionned here.

Paul in another thread has suggested that I start from the Keypad library. Good hint, since I'm a beginner!

Is there anyone here having developped a solution for this? Because I still have questions before moving on: (here I repeat things posted in the previous thread, but this forum section seems a better fit)

One thing I do not understand with the keypad libraryis the debounce time of 10ms. Does it imply a sort of wait(10ms)? If so when a keyboard needs multiple scans (large number of keys), do we have to sum up all those times for a total scan time. For instance, the keyboard I'd like to use is a 61-keys, organize as 8x8 matrix. Does it result in 80ms++ for a total scan? And actually, it is even larger because each key is a double one to express velocity, so it's 2x8x8, so 160ms. And it is even worse since I'd like to have 3 keyboards (this is for a virtual pipe organ), but here if one controller is not enough, I will just make 3 of them.

I then have to add timing info to estimate the key velocity:
  • scan the upper part of the keyboard (8x8, or 4x16 if I can afford 2 bytes for reading and the 20 required pins it implies [actually 4x16 won't bring any value since we cannot read 16 bits in a raw]) and record the times
  • scan the lower part
  • derive the velocity for each pressed key using time difference

Any comment or suggestion?

[EDIT]After reading Keypad.cpp source for Keypad lib, I think I can forget about the total time question: the debounce time is the minimal time taken by the full scan, so here after the 2x8 scans. So it's not adding this time for each scan.[/EDIT]

Thanks!
 
Last edited:
Virtual organs latency

Hi !
I have designed several MIDI interfaces for VPO (Virtual Pipe Organs). I used HALL effect sensors, which don't absolutely need debounce time, as the ON-OFF transition is single.
Of course, classic contacts like FATAR are generating bounces, and one must wait from 5 to 10mS, before sending the NOTE-ON MIDI event.
When several keys are hit, one must add all the different debounce delays !

For demanding organists, (even non professionnal ones), this debounce delay is absolutely unsupportable.
Moreover, VPO softwares have also their own latency.
You can see my VPO (and also the pipe organ I built, alone, on:
http://pascal.leray.free.fr/musique/orgue_liturgique_virtuel_en.html

I used 8051 but I am planning now to use my TEENSY 3.1, for the keyboards, but also for the VPO software.
Maybe with the audio board.
With all my congratulations for your project.

Pascal

http://pascal.leray.free.fr/index_en.html



Hello,

I plan to build a 3 keyboards console for a virtual pipe organ (I'm not a player myself), using 3 Fatar TP/8 keyboards and Teensy to "midify" them. It seems that I'm not the first one (great!), and it has already been mentionned here.

Paul in another thread has suggested that I start from the Keypad library. Good hint, since I'm a beginner!

Is there anyone here having developped a solution for this? Because I still have questions before moving on: (here I repeat things posted in the previous thread, but this forum section seems a better fit)

One thing I do not understand with the keypad libraryis the debounce time of 10ms. Does it imply a sort of wait(10ms)? If so when a keyboard needs multiple scans (large number of keys), do we have to sum up all those times for a total scan time. For instance, the keyboard I'd like to use is a 61-keys, organize as 8x8 matrix. Does it result in 80ms++ for a total scan? And actually, it is even larger because each key is a double one to express velocity, so it's 2x8x8, so 160ms. And it is even worse since I'd like to have 3 keyboards (this is for a virtual pipe organ), but here if one controller is not enough, I will just make 3 of them.

I then have to add timing info to estimate the key velocity:
  • scan the upper part of the keyboard (8x8, or 4x16 if I can afford 2 bytes for reading and the 20 required pins it implies [actually 4x16 won't bring any value since we cannot read 16 bits in a raw]) and record the times
  • scan the lower part
  • derive the velocity for each pressed key using time difference

Any comment or suggestion?

[EDIT]After reading Keypad.cpp source for Keypad lib, I think I can forget about the total time question: the debounce time is the minimal time taken by the full scan, so here after the 2x8 scans. So it's not adding this time for each scan.[/EDIT]

Thanks!
 
So, which keyboard?

Thanks for your answer. Meanwhile, my choice moved for Fatar TP 60 (it seems that there is a consensus around considering that the touch feeling is closer to typical organ keyboard). But, the bounces problem may be (is?) the same: what keyboard would you recommand?

For the pedalboard, I've just bought a second-hand pedalboard. I just have to refresh it and add the electronic part. For this, I was planning on reed siwtches.

Hi !
I have designed several MIDI interfaces for VPO (Virtual Pipe Organs). I used HALL effect sensors, which don't absolutely need debounce time, as the ON-OFF transition is single.
Of course, classic contacts like FATAR are generating bounces, and one must wait from 5 to 10mS, before sending the NOTE-ON MIDI event.
When several keys are hit, one must add all the different debounce delays !

For demanding organists, (even non professionnal ones), this debounce delay is absolutely unsupportable.
Moreover, VPO softwares have also their own latency.
You can see my VPO (and also the pipe organ I built, alone, on:
http://pascal.leray.free.fr/musique/orgue_liturgique_virtuel_en.html
 
You think we can manage the sound rendition on the Teensy itself? One problem I imagine is that a typical VPO trades CPU pressure for memory/latency pressure: it has to render multiple large wav files with minimal latency. The on-board memory is too small, SD cards are too slow (at least latency is too high). What is your idea?

I used 8051 but I am planning now to use my TEENSY 3.1, for the keyboards, but also for the VPO software.
Maybe with the audio board.
With all my congratulations for your project.

Pascal

http://pascal.leray.free.fr/index_en.html
 
Organ keyboards

Hi !
I recommend classic Organ keyboards, with Hall effect sensors, as I did on my own keyboards. Main advantages : Absolutely NO latency, undefinite reliability during time, and NO BOUNCE : Hall effect sensors are swithching frankly and only once, without bounce.
Pascal
 
Hi !
Of course, wav files are too large for the 64 KBytes memory. But maybe another 32 or 64 bits ARM processor could manage 2 or 4 MBytes of fast RAM. (as it's done on INTEL 80xx). Moreover, wav files datas can be reduced by using only 2 or 3 notes per octave. Thus one could spare lots of memory. And one could use more processors for several stops.
Best regards,

Pascal
 
I've found real keyboards, but the price cannot fit in my hobby project (except maybe if you know good quality/price ratio provider). It seems that re-wiring a Fatar TP/60 with Hall effect switch could be a solution. One potential issue is the weight of the magnet.

Anyway, I'm starting on this and the debounce problem is new for me and still unclear. Looking at the Bounce library, it appears to me that it just associates a timer to a key. If the debounce time is set to 5ms, it prevents more than 1 read every 5 ms. For 1 key, one can see this as a delay. And the lib implementation here is indeed problematic because, as you indicated in your previous post, worst case is to sum-up all those waits because the wait is inside the read procedure (update() in the lib). I think we can workaround this by not using this library and having bounce delay on the main loop only: a full scan (scan KB1 part1, KB1 part2, ..., KB2 part8) will occur only once every 5ms (provided the duration is below 5ms, which seems no problem for the Teensy). As a consequence, those 5ms will roughly translate into the time resolution of the keyboard. Which is still less than 1/10 of a 64th.

*But* I have to verify this for real...

Hi !
I recommend classic Organ keyboards, with Hall effect sensors, as I did on my own keyboards. Main advantages : Absolutely NO latency, undefinite reliability during time, and NO BOUNCE : Hall effect sensors are swithching frankly and only once, without bounce.
Pascal
 
Last edited:
The weight of the magnets is irrelevant : I am using magnets 3x5x20mm. Largely under the key weight.
 
Are high quality pipe organ sounds available in SoundFont or any other high quality, openly documented wavetable format?
 
This site has a list of free/demo organ sample sets, plus lots of other stuff.
Each WAV file (one note) of a sample set with no reverb (which makes the sample short) can be on the order of 200+kB which means a Teensy3.x is out of the question.

This site has various versions of a free organ, including one in Soundfont format (link at the bottom of the page).


Pete
 
Last edited:
Hi Paul !
Indeed, the TEENSY concept is very attractive, as one can compile and load directly C++ code, without any boring operating system. It could be extended to other hardware boards, with 2 or 4 GByte memory, 2x16bits audio, and a fast ARM 32 bits processor, and an USB second access to an SSD or memory key.
 
Of course, TEENSY 3.1 can't load such huge files. But some new prototype based on a powerfull 32bits ARM, with 4GBytes of external RAM memory and 2x16bits audio output could do the job.
 
In theory, pretty much anything is possible with capable hardware and enough programming work. In reality, many of the software features you might wish existed never happen, only because nobody invests the incredible amount of work necessary to write them.

Just to give you a realistic expectation, almost all the Teensy Audio Library code is written to use the special DSP extensions of the ARM Cortex-M4 processor. It can't run on any other ARM chips, even high end Cortex-A15, because they lack the M4's specific DSP instructions. Later this year, Cortex-M7 chips are supposed to start appearing on the market. M4 & M7 are the only processors from ARM with these DSP extensions.

At some point, PJRC will almost certainly make a M7-based board.

But the M4 is quite capable. SD card latency is the one really weak spot. That's why I designed the audio board with a place to add a SPI flash chip, which is 16 MByte. When I write an object to play (converted) soundfont, it'll almost certainly use the SPI Flash chip for the soundfont data.
 
great info, I'm working on a hex guitar pitch to midi converter with teensy 3.1, I'm interested in this stuff, I might add an onboard wavetablesynth
Small question, Paul: will the M7 feature a FPU? I'm getting a slight headache from integer math.. ")
 
Dear Paul,

I have now designed sets of MIDI/USB boards using Teensy 3.1 . (fantastic computer !) Response time <1mS, fairly simple.
http://pascal.leray.free.fr/web_org/org_en.html

I am planning now to design a virtual pipe organ using soundfonts and the Teensy audio module.
How many waves (recorded on the SD card) can be mixed simultaneously, in order to comply to polyphony, (several keys simultanoeus) and multitimbral (several stops/registers simultaneous) needs ?
Thanks for your advice !
Pascal
 
Pascal,

are there by chance any schematics/plans to build a PCB (e.g. at OSH Park)? Or is ther any possibility to buy it from you? I would be very interested, because I use an old WIRA system with my two Fatar keyboards and I would like to replace it with a Teensy 3.2 - also because so I'm able to add some functionality by myself.

BTW: I got along with the development of Hauptwerk, as I started a resembling project by myself years ago and dropped it when I contacted Martin Dyde and became aware he already went far on this path. The development of MyOrgan/GrandOrgue came up because the users had not been happy with the licencing mode of some sample providers, because they encapsulated the system and made it hard to use sample sets of the first versions of Hauptwerk in other environments. MyOrgan was at least a "Hauptwerk I" clone which did not develop so much further with the technologies Hauptwerk uses, so technically they may not be compared.E.g. given GrandOrgue uses convolution revern, in Hauptwerk, the room ambience is in the samples themselves, you may sometimes use "dry" samples or the samples of the genuine organ in the genuine location. The reasons of the development had been comprehensible but implied some "mixed feelings" about the development. For simpler organ sets, GrandOrgue might be ok, but with the underlying technology of Hauptwerk you have tons of possibilties to achieve a "real organ experience'. Example given - just play an 8" Flute register and then, if availabe, play the lowest Posaune 16" at the same time. When the organs wind capacity isn't overwhelming, normal the flutes will break in or collapse a little - you don't have this wind conditioned behaviour on other organ sample players, as I know. But I will not "restart" another "Hauptwerk vs. MyOrgan fight" - I think, these times have passed and we move on.

@Paul: a good Chruch Organ soundfont is located here: Jeux, a pipe organ soundfont

- Manfred.
 
Dear Manfred,

Indeed, I designed a PCB board with TEENSY 3.1, which can be seen on:
http://pascal.leray.free.fr/web_org/org_en.html
Which is running fine. This board can proocess up to 6 midi/keyboards, including FATAR matrixed keyboards.
Plus 64 digital inputs, 32 power outputs
Can control real pipe organs, using my power output real organ controller boards.
I can supply these boards.

Aufwiedersehen,

Pascal


Pascal,

are there by chance any schematics/plans to build a PCB (e.g. at OSH Park)? Or is ther any possibility to buy it from you? I would be very interested, because I use an old WIRA system with my two Fatar keyboards and I would like to replace it with a Teensy 3.2 - also because so I'm able to add some functionality by myself.

BTW: I got along with the development of Hauptwerk, as I started a resembling project by myself years ago and dropped it when I contacted Martin Dyde and became aware he already went far on this path. The development of MyOrgan/GrandOrgue came up because the users had not been happy with the licencing mode of some sample providers, because they encapsulated the system and made it hard to use sample sets of the first versions of Hauptwerk in other environments. MyOrgan was at least a "Hauptwerk I" clone which did not develop so much further with the technologies Hauptwerk uses, so technically they may not be compared.E.g. given GrandOrgue uses convolution revern, in Hauptwerk, the room ambience is in the samples themselves, you may sometimes use "dry" samples or the samples of the genuine organ in the genuine location. The reasons of the development had been comprehensible but implied some "mixed feelings" about the development. For simpler organ sets, GrandOrgue might be ok, but with the underlying technology of Hauptwerk you have tons of possibilties to achieve a "real organ experience'. Example given - just play an 8" Flute register and then, if availabe, play the lowest Posaune 16" at the same time. When the organs wind capacity isn't overwhelming, normal the flutes will break in or collapse a little - you don't have this wind conditioned behaviour on other organ sample players, as I know. But I will not "restart" another "Hauptwerk vs. MyOrgan fight" - I think, these times have passed and we move on.

@Paul: a good Chruch Organ soundfont is located here: Jeux, a pipe organ soundfont

- Manfred.
 
How many waves (recorded on the SD card) can be mixed simultaneously, in order to comply to polyphony, (several keys simultanoeus) and multitimbral (several stops/registers simultaneous) needs ?

SD cards have high latency through SPI. Most cards can play 2 or 3 files simultaneously. Use File > Examples > Audio > HardwareTesting > SdCardTest to test your SD card's performance.

Usually SanDisk Ultra are the best cards. Many no-name or Sandisk counterfeits from China perform slowly, sometimes not even fast enough to play 2 WAV files.

Use the 8 pin SPI flash chip if you need to play more than 3 sounds simultaneously. It's capable of playing about a dozen sounds.
 
Polyphony need 12 simultaneous wav files, (10 fingers + 2 feet) and multi stops need to multiply this number by the number of stops.
 
AFAIK you have to multiply this 12 possible notes with the number of active registers - then you know the real polyphony the system has to provide. And if there are couplers. the number goes up. It's not very seldom youn find numbers in the thousands. Let me quote the GarnOrgue manual "The default setting of 2048 should provide a reasonable starting point on a 1GHz CPU." meaning the max. amount of audio samples (residing in the RAM) played at the same time.
 
OK ! 2048 is of course a maximum. That's why one must have wav stored in RAM. But for embedded, particular applications, for example a 16' or 32' pedal extension for small organs, only 2 simulaneous notes could be sufficient. And one can multiply the Teensy number. Solving the steaming and loop process could lead to a fairly simple solution. Have you watched my website and my Fatar interfaces using Teensy ?
 
Ok, in the perspective of distributed computing this might be imaginable. Let's say one Teensy per register - then the polyphony is sufficient, if not a variety of samples (legato, staccato etc.) and release samples must be organized. The big advantage of microcontroller based solutions is the near-realtime handling of the data because of the lack of an os. But anyway I'm afraid one will find the limits of the system when using highly sophisticated samples with the purpose to also project the instruments ambiance. Also the transient effect of larger registers needs at least more memory space than smaller ones. Contrebombarde with Teensy? :cool:
 
After all, a 32/64bits Pentium is also a microprocessor : Why not develop a PJRC TEENSY PC ? Without operating system, but with all the libraries.
It would be the ideal platform merging very high computing power, large memory RAM, SIMD instructions, and low cost. Watch the recent micro-PC's in stick format, with very affordable price, comparable to Arduino or other low cost systems.
The outstanding, major interest of TEENSY is that there is no WINDOWS nor UNIX. But all direct accesses and functions to fundamental functionnalities.
After all, except for general purposes PC, operating systems is unnecessary. The remarkable work that Paul has achieved could be transposed on Pentium or AMD platforms.
Concerning Wav sample, I think that the most important is the quality of the samples themselves. I'm living near an historic, 1774 organ, in a very nice 12th century church, and "ambiance" is well stored in wet samples. VPO software has only to output these wav files, with no effect.

General Music designed in the past a very good sound board, with his own microprocessor. sound files were stored in REPROM. Limited stops but the result was absolutely remarkable. Unfortunetely, General Music stopped this production. One need now similar hardware, and a TEENSY-PC would be a very good product.
Pascal
 
Status
Not open for further replies.
Back
Top