Question about velocity and the license

[haghish]

Thanks for the great work RObert. I'm willing to contribute to this project but I wonder:

1. what is the license of the code? It doesn't mention it anywhere.

2. the feature I am VERY interested in is defining different wave files for different velocities, or ranges of velocities. It seems that currently this feature is not programmed, or is it? If not, do you have any suggestion where to start and how it should be implemented?

Cheers,

[robertsonics]

This is a PC configuration tool for the SparkFun WAV Trigger and Tsunami products. There is no license as such for this - I'm just making the source code available to the public. The firmware for the SparkFun products is not open open source, is copyrighted and only intended for use on those hardware devices. I don't release the source code for the firmware. I do sell source code licenses, but the cost of the license only makes sense if you are manufacturing large numbers of your own product.

The feature that you mention would be an enhancement to the product firmware, not anything that could be implemented by this configuration utility. I understand the request, and may get to it as some point, although I'm not sure how the tracks would be assigned to velocities in any manageable way.

[haghish]

thanks Robert. This feature would turn Tsunami to a product that can be used in custom-made electric pianos. As a suggestion, a rather common method for assigning wav files - with different velocities - to a note is file naming. A resonable implementation of this procedure in python can be found here: https://github.com/josephernest/SamplerBox, for a similar product for Raspberry pi.

However, having this feature in a board like Tsunami can be a big advantage for skipping the booting time of a single-board computer.

PS. I am not intending to manufacture the board in a large amount. I am in the process of developing a custom epiano for a particular micro-tonal project and I am in need of a sound system that plays one virtual instrument, but with a high quality, adequate polyphony, and support for sustain, pitch, and velocity. Tsunami has them all, but lack of layering velocities makes it less useful for playing instrument sounds such as piano.

If you are aware of any alternative board that meets these characteritics, I would highly appreciate your suggestions.

[robertsonics]

I can think of a way that may be relatively easy to implement without being just a special case. What if the velocity mapped to sound banks? Right now, there is the concept of a MIDI Bank, which shifts the track assignments by 128. In Bank 1, MIDI Note number 1 maps to track 1, and in Bank 2, MIDI Note number 1 maps to track 128, and so on. I could have velocity zone map to MIDI Banks so that you'd separate the tracks numbers in each velocity zone by 128.

How many velocity zones would you need and can you live with fixed velocity values for the zones?

Also, once you purchase a WAV Trigger or Tsunami from SparkFun, you can do whatever you want with it, including embedding it into your own product.

[haghish]

It's interesting that you're suggesting exactly what I had in mind, when I forked the repository! That'd definitely be possible and a slight modification to the WTConfig would allow the user to specify in which bank the velocity is assigned. Or, it can be done automatically, i.e. the program assigns the higher velocities to the higher banks (preferable, I guess).

Tsunami recognises 4096 wave files, divided by 88 notes, it seems it can map up to 45 velocities for each note. If the sound bank hack works, then basically the higher the possibilities the better. In my case, I'm considering each SD card for a single instrument and will try take a full advantage of the Tsunami, while trying to keep the limit of 10ms delay. I'd excessively sample the velocities, so minimum of 25 would be usable. 10 or 15 would be too little for a solo instrument. So the higher the better! 👍

I assume with this implementation, any midi channel would be playing the piano sound? In my case, this is very favourable because I have multiple midi channels with different tunings playing the same instrument. In the current SF2 implementation I define the same instrument on different channels. But you may want to make this optional, in case others would want to avoid that (just a thought).

Finally, THANK YOU for following the idea. This would be very enabling for Tsunami and can make it very attractive for those who want a decent sound module without investing thousands or including a small linux underneath the sound module. I'm waiting for the delivery of my kit and I have a few thoughts to share about improving Tsunami. I would be very happy to share them with you. You could reach me at haghish{at}med.uni-goettingen[d0t]de, or let me have yours (couldn't reach you from your site).

Cheers

[robertsonics]

Tsunami uses all 128 MIDI note numbers per bank (so as not to limit controller note numbers). Therefore the max number of banks is 4096 / 128 = 32. I'd probably not be interested in any scheme that limits banks to a number less than 128 notes - too specific. Also, Tsunami allows for Omni mode, which basically ignores the MIDI channel number, and any channel would work the same.

To simplify the configuration, I'd suggest that there would always be the same number of velocity zones and the same velocity values for each zone. What should those be?

[haghish]

32 is great and is used in professional sound banks! However, answering the last question with a solid rationale is not easy at all (https://strongenging.com/papers/VelocityCurves.pdf, see page 5). I have a suggestion to keep the configuration program as simple as is, while applying all of these velocities and making them flexible for those who need to use the board on stage.

1. Before I explain my suggestion, let us make a distinction between wav files assigned to a velocity zones and the loudness of the sound. I assume that you don't to manipulate the loudness of the wave file within the zones. i.e. if a file is assigned to a velocity zone 70 to 89, the loudness of the sound would be the same? What if the user only includes 2 sounds per note, he'd need the volume adjustment function. So would that mean you'd add a box for checking automatic loudness? (I won't need that, but I'm trying to think as general as I can).

2. When you suggest specifying fixed velocity zones, is that because you can add a drop-down menu where users can click to which zone they want to add a file? Or just a button that activates predefined velocities?

3. In case of drop-down menu, would it be possible to define several predefined schemes to choose from? Although my solution below should be even better than this...

---

Velocity Zones

Intuitively, with 32 velocities, one might say, a linear vector with equal steps of 4 (128/32) would be just fine. In practice, however, there are more sounds needed for lover velocities and a handful of noisy ones for the forte fortissimo (not always, depending on the instrument.). The optimal value would vary based on the instrument, making it impossible to come up with a rule of thumb (at least for me). A Rhodes piano has different sound characteristics than an a grand piano and I would sample them quite differently...

Suggestion

I understand the importance of a clean and simple GUI and I think a drop-down menu is a great idea. But my add-on suggestion would be to make the program look for 2 optional vectors of length 32, specifying the beginning and ending of each zone in the tsunami.ini file. For example:

#VEL_ZONE_LOW 1,5,10,15,20,...
#VEL_ZONE_HIGH 4,9,14,19,24,...
#VOL_ADUSTMENT FALSE

Presumably, you could just add a button saying implement velocities that adds this code in the file. Then, those who want to edit it, they're free to do so. In this case, a check box about an automatic volume adjustment would come handy, in case someone wishes to create a sound with a few velocities only. Only a few thought, trying to guess how you've programmed it or how you'd implement it...

If this solution (or alike) require so much work, I would need a few days of literature search to see what is the state of the art in this regard. My knowledge is very limited and I had postponed the sound engineering aspect of the project for later. But these flexible velocities are really handy.

Cheers, and thank you again for following the idea.