Wav Trigger / Tsunami Advice needed

Sensors Sound & Audio
1

hi there!

for a kind of mellotron-project, i need to run 12 stereo loops continuously. only need a single stereo output.

12 buttons would control volume on and off, without retriggering - you would hear the corresponding loop where it is at that point in time. fade in and out times to be determined by two pots.

the problem i’m having:

i own a WAV Trigger, which can theoretically do 14 stereo loops.

unfortunately, the maximum MIDI fade time of 2 seconds is too fast for my purposes.

so i tried running serial control over arduino, so i can have longer fade times… however, on the other end of the scale, the wTrig.trackFade command glitches out on me under ±300 ms, which is too long to serve as a useful minimum.

and that’s only when using it on a couple of tracks, like two or three, where i would really like 12 note-polyphony.

i imagine that would only make matters worse.

my questions, then:

  • is this something that is addressed with the latest firmware of the WAV Trigger?

i will admit i’m not entirely sure what firmware i’m running right now - WAV Trigger is about two years old.

i would have to buy an FTDI breakout or similar to perform an update, if that is at all needed.

  • is this something that can be solved more easily using the Tsunami?

(seamless looping, more memory so maybe less glitching?..)

it does feature built in midi, which is alluring, but i can’t seem to find any specs on actual attack/decay time lengths - (if it is at all possible to ONLY fade volume, and not retrigger with every key press…)

if Tsunami sticks to the 2 second limit, it’s back to serial control.

  • i am looking at the Bela / Beaglebone Black combo, since i can program that using PureData, which is nice.

i mean, it might be less tedious than trying to program my own fade protocol which would bump into the limits of the WAV Trigger anyway :slight_smile:

any experience/thoughts on that?

thanks a lot for your ideas and input.

gr, kris/Remork

2

There should be no relationship between the number of voice playing and the ability to perform fades. Any issue you’re having with fades is not dependent on how many voices are playing. I’ve tried really hard to never allow “glitches”, and the maximum number of voices was determined in part by being able to do everything all at once with any degradation in audio.

Now, to the issue with fade times, I did overhaul the fader algorithm in the last shipping release which in part addressed short fade times, and although that was quite some time ago, it’s certainly possible that you are not up-to-date with firmware. I’m not aware of anything that would cause “glitches”. There is a lower limit of 3ms in the current firmware.

All you need to update the firmware is a USB-to-TTL serial adapter. The connector pinout directly supports an FTDI-Basic, but any adapter should work. Just make sure that it’s TTL level, not RS-232.

A potentially bigger issue is that the WAV Trigger cannot do truly seamless looping - there will always be a gap of something between 0 and 3ms at the loop point. You can mitigate that somewhat by looping your sample in the audio file and just making the file be really long, but eventually you’ll reach the end and there will be a slight tick. Tsunami does loop seamlessly. It also shares the same fader algorithm.

Hope this helps.

3

thank you so much for the quick reply!

i think i’m hearing the same thing described here:

https://github.com/robertsonics/WAV-Tri … y/issues/1

notably, “I heard some digital clipping when I increased the fade time up to 200ms from 0”.

but this probably dates back to earlier firmware (2015…), so i might indeed need an update.

i’ll get me an FTDI Basic asap.

my assumption of a track count & fade-ability relation was based on this:

https://github.com/robertsonics/WAV-Tri … al-Library

“If you are connecting a continuous controller that can change rapidly for volume or sample-rate control, you should use a timer to send changes only every 10 or more msecs. You can, of course, experiment with this. If you’re only ever playing 1 or 2 tracks at a time, you’ll likely be able to get away with sending volume changes more frequently than if you are playing 8 tracks at a time.”

since the trackFade command results were not quite satisfactory for the shorter attacks, i was planning on sending my own calculated track volume changes. i assumed that would mean testing what the minimum interval should be when changing 12 track volumes at a time, hence my remark. sorry if that was a bit hazy.

ideally, i would love to have fade times ranging from zero (<30ms) up to about 5 or 6 seconds.

do you think - with the updated firmware and latest Arduino libs - that’s realistic when using the trackFade command?

that would be a LOT easier :slight_smile:

4

oh, i might add - i’m not too worried about the gap in the loop just yet.

the files are quite long, and i don’t mind having fades at the beginning and end of the file - there’s a lot of volume changes in the files themselves anyway, so an extra 3ms of silence is not going to make the difference.

5

The issue with sending rapid volume volume changes is related to activity on the serial port, not dsp processing. Ironically, the highest priority interrupt in the WAV Trigger (and Tsunami) is the one for receiving bytes on the serial (and MIDI) port. The reason is that if you miss one byte, you miss the entire command, which could for example be a MIDI Note-Off message. That results in a stuck note, which is bad. So if you flood the serial port with constant data, it takes the processor away from servicing the audio engine, and eventually it will hiccup. That’s the primary reason I implemented fades in firmware - to alleviate the need for sending a lot of serial commands to produce smooth volume changes. (Pitch bend is much more forgiving - our ears don’t react the same to small jumps in pitch compared to jumps in volume, so you can get away with sending pitch bend message less frequently.)

6

thanks again. that makes sense.

FTDI is on it’s way, will report back when i got round to updating and testing.

(which might be a while, unfortunately - i have a few high priority interrupts of my own to deal with.)

7

FTDI arrived, firmware update succesful! updated to 1.28.

i’m currently running and modifying the WTrigBasic.ino sketch from an Arduino Mega2560 to try everything out.

that all seems to work, and fades are indeed a LOT smoother than before, so hooray for new firmware.

however.

bumping into some issues:

  • i wanted to use serial port #2 on the Mega. uncommented the relevant line in the wavTrigger.h lib, but i still seem to be outputting serial commands on pin #46 as per the AltSoftSerial library.

i’ll attribute this to user error - i’ll get my head wrapped around that one eventually.

  • but, bigger problem for me:

when i’m using the full volume range (i.e. -70 to 0), the trackFade commands become unresponsive under 105 ms.

let me explain. for example: if i modify WTrigBasic sketch Case0:

wTrig.trackGain(2, -40); // Preset Track 2 gain to -40dB

wTrig.trackPlayPoly(2); // Start Track 2

wTrig.trackFade(2, 0, 2000, 0); // Fade Track 2 up to 0dB over 2 secs

to

wTrig.trackGain(2, -70); // Preset Track 2 gain to -70dB

wTrig.trackPlayPoly(2); // Start Track 2

wTrig.trackFade(2, 0, 104, 0); // Fade Track 2 up to 0dB over 104 msecs

nothing happens. volume doesn’t change at all. 105ms and up: works perfectly.

i tried it for both fading in and out, and in several places in the sketch. it’s pretty consistent, so i’m guessing it’s messing up the calculations in some way.

through trial and error, i found there’s a relationship between the short fade times and the volumes used (independent of the master gain setting, by the way.)

at -70dB, minimum fade time is 105 ms.

however, if i want a 100ms fade time, the most i can get is -66dB.

now, if i’m aiming for some kind of natural feeling musical instrument, i would ideally want under 10ms of fade time…

unfortunately, 10ms fade time will only yield -6dB maximum difference!

even if i compromise on responsiveness, 20 ms sits at -12dB and 30ms at -20dB.

now, my plan was to run 12 loops simultanuously, never turning them off and only using the track volumes for control.

even at -20dB per track, that becomes quite the noise floor.

is this expected behaviour, or am i doing something wrong here?

i realise i could code it so that anything under 100ms on the Attack pot (range 0 to 5 seconds) becomes an instantaneous volume command, bypassing the trackFade command. and i can then limit everything to -66dB to be acceptable.

it just seems… i dunno… too bad :?

8

ok, so i just upgraded to firmware 1.31, curious about the ‘improved fader performance’.

a lot better indeed!

it’s not entirely full range, but i can now get a 10ms fade with a volume range of -52dB. (0 to -52, -2 to -54 etc.)

promising! on to testing with multiple tracks.

sorry if i complained too quick.

maybe it’s useful for others bumping into the same issue.

9

testing with a keyboard and multiple tracks: everything seems to work, so far.

at least on a technical level.

on a musical level, though, still not entirely there.

if i do want to get that ‘noise floor’ down (aka the combined volume of 12 idle tracks when i’m not pressing any keys), it seems my best option is to shift that 52 dB range i have, so it spans -18dB to -70 (fully muted). that way all tracks are indeed muted after their fade-out. that makes quite the difference, but the 18 dB drop does feel like a bit of a sacrifice.

and i will admit i didn’t expect the loop point ticks to be quite so audible - they are less than pretty indeed, and present even with all track volumes at -70.

well, i’m really glad i got this far, and i’m sure i’ll be able to use it for other (more appropriate?) purposes, but maybe the wavTrigger just isn’t the right tool for this particular job.

i refuse to give up on the idea though… might have cleaner results with the Tsunami… :smiley: