Stephane Morisse

- if I start the transport after loading a file, it starts to play immediatly. Didn't really investigate this issue but I don't understand why.

- there's a click at the end when slowdown is on. How could I change that ?

Then, as I constantly had to save and leave the editor in Live, and because I suspected that the result would be better using [line~] instead of [line], I turned to Max 6.05 and made this :

- full stop (sending a message '0' to [sig~] doesn't work.

- when slowdown is selected using the [toggle], the behaviour isn't what I expected : if the sample doesn't play, it works, but if the sample plays instead of slowing down from normal speed to 0, the speed decreases from higher than 1 back to 1

These are probably very simple mistakes from me so...

This does work as intended except that :
- if I start the transport after loading a file, it starts to play immediatly. Didn't really investigate this issue but I don't understand why.
- there's a click at the end when slowdown is on. How could I change that ?

But (look at the red rounded objects) :
- full stop (sending a message '0' to [sig~] doesn't work.
- when slowdown is selected using the [toggle], the behaviour isn't what I expected : if the sample doesn't play, it works, but if the sample plays instead of slowing down from normal speed to 0, the speed decreases from higher than 1 back to 1

These are probably very simple mistakes from me so...


tapestart-emulation

Anyone on this one ? Or is it a bug ? Am i the bug ?

If you're emulating a tape machine, you probably only want to have one line~ going into groove~. It will simplify things considerably. The messages look like this:

start: 1 $1 (speed up to this over n ms (note that I don't go to 0 first, since if it's already playing or slowing down I don't want it to start from a stopped position)

stop: 0 0 (go to 0 over 0 ms. You might try a slightly longer time to emulate a quick, but not instant stop (maybe 20-100 ms?))

slowdown: 0 $1 (like start, but now slowing down)

Also, it's REALLY important to block the potential DC signal coming out of groove~ using a highpass filter.

If you're emulating a tape machine, you probably only want to have one line~ going into groove~.  It will simplify things considerably.  The messages look like this:

start: 1 $1 (speed up to this over n ms (note that I don't go to 0 first, since if it's already playing or slowing down I don't want it to start from a stopped position)
stop: 0 0 (go to 0 over 0 ms.  You might try a slightly longer time to emulate a quick, but not instant stop (maybe 20-100 ms?))
slowdown: 0 $1 (like start, but now slowing down)

I know it sucks to be a noob on this list, but it's worth it! I've posted several times with no answers. Hang in there. The questions only get harder ;-)

First, I'm pretty much a noob as well. I've been "playing" with Max for a little over a year and still have volumes to learn. I'm a little hesitant to give advice.

With that in mind... I noodled with it a bit and apparently the buffer~ object is receiving "conflicting" information from the the START & STOP segments of the patch. START sends its signal value to the buffer~ at the audio rate continuously AND STOP is sending its signal as well. They are additive, apparently, in the buffer~ object and are "canceling" each other out; i.e. START is sending "1" and STOP starts by sending "1" and decreasing in value. That's why the speed doubles when you hit STOP and levels off at unity ("1") when the line~ object completes its function, the buffer~ object is calculating the sig~ inputs from both START and STOP giving a starting value of "2" and floating to "1" at completion.

I added a selector~ object that switches the signals between START and STOP. Seems to work.

I'll post the patch with changes if you like.

I know it sucks to be a noob on this list, but it's worth it!  I've posted several times with no answers.  Hang in there.  The questions only get harder ;-)

First, I'm pretty much a noob as well.  I've been "playing" with Max for a little over a year and still have volumes to learn.  I'm a little hesitant to give advice.

With that in mind... I noodled with it a bit and apparently the buffer~ object is receiving "conflicting" information from the the START & STOP segments of the patch.  START sends its signal value to the buffer~ at the audio rate continuously AND STOP is sending its signal as well.  They are additive, apparently, in the buffer~ object and are "canceling" each other out;  i.e. START is sending "1" and STOP starts by sending "1" and decreasing in value.  That's why the speed doubles when you hit STOP and levels off at unity ("1") when the line~ object completes its function, the buffer~ object is calculating the sig~ inputs from both START and STOP giving a starting value of "2" and floating to "1" at completion.

I added a selector~ object that switches the signals between START and STOP.  Seems to work.

Being a noob here doesn't suck : until now, I've always had clever and constructive answers to even the most basic questions.

So thanks to both of you : Peter for another take on that one, and mradentz for clarifying what I suspected... I'm now going to try to solve the click issue at the end. I thought about triggering a [line~] to a [*~] at time (t-20ms) for example to make a quick fade out on the output amplitude. Does it make sense ?

Being a noob here doesn't suck : until now, I've always had clever and constructive answers to even the most basic questions.
So thanks to both of you : Peter for another take on that one, and mradentz for clarifying what I suspected... I'm now going to try to solve the click issue at the end. I thought about triggering a [line~] to a [*~] at time (t-20ms) for example to make a quick fade out on the output amplitude. Does it make sense ?


Yeah, I'd recommend that if you want a cleaner sound.

So here what I came to deal with the click at the end of slowdown. It seems to work but how could it be improved ?

I'd just like to briefly chime in, on the n00b topic here, especially given my forum name : )

I've been using Max for 5 years, initially introduced to it by Eric Lyon, Ben Knapp and Maarten van Walstijn (@ SARC) as part of their MA in music tech course (it was around Max 4.n). It was delivered in a kind of sink-or-swim format, which expedites learning if you are so inclined. The only text I had was the Curtis Roads core text and the Max documentation. As a "lazy-learner" who prefers to do and fail rather than read, do and succeed, I spent many hours badgering the forum for solutions to n00b problems, and have always and since found the members here patient, helpful, knowledgeable and etc.

I am in no way reprimanding any comments here, just wanted to insert a timely reminder that this forum, among many to which I contribute and participate, is far and way the most helpful, accessible and informative. If you occasionally have to wait for a response, have a tinker with your patch and re-frame the question, keep your topic at the forefront (without double-posting of course).

Off to rock Ballyclare with some METAL now,

(yeah, I ditched FB a year ago, and obviously miss it :p)

Hi
I'd just like to briefly chime in, on the n00b topic here, especially given my forum name : )

Off to rock Ballyclare with some METAL now,
(yeah, I ditched FB a year ago, and obviously miss it :p)

Sorry all. "Suck" was decidedly a poor word choice.

I was motivated by the phrase "Am I the bug?" to offer encouragement and maybe a sense of belonging. TRULY no disrespect intended.

I am, personally, completely intimidated by the collective and individual intelligence and creativity displayed by the Max community and usually just "lurk" on the list. I was surprised to find that maybe I did actually have something to contribute to the group, and maybe make someone who sounded very frustrated actually feel better.

StephaneMorisse... thanks for the opportunity and good luck with all your endeavors, especially with Max.

Sorry all.  "Suck" was decidedly a poor word choice.

I was motivated by the phrase "Am I the bug?" to offer encouragement and maybe a sense of belonging.  TRULY no disrespect intended. 

StephaneMorisse...  thanks for the opportunity and good luck with all your endeavors, especially with Max.

Hi Stephane, here's a different way of doing the volume. It simply watches the speed of the playhead and turns off the volume when it's at or below 10%. I use slide~ to smooth that transition from off to on and vice versa. (note the different attack and release times) Try turning it off and on rapidly.

The advantage of this is that it's not dependent on timing, so whether you're going over 3 seconds, or 3 milliseconds, it's just going to cut the volume out whenever the tape is too slow (you can change that threshold as you like). In my personal opinion, solutions like these are desirable because it's one less thing that can go wrong in terms of control-rate timing, which is always where the greatest variance seems to happen, especially as patches grow complex. Plus, it's probably at least as efficient as using line~ and might even be more so. 

Hi Stephane, here's a different way of doing the volume.  It simply watches the speed of the playhead and turns off the volume when it's at or below 10%.  I use slide~ to smooth that transition from off to on and vice versa.  (note the different attack and release times)  Try turning it off and on rapidly.

The advantage of this is that it's not dependent on timing, so whether you're going over 3 seconds, or 3 milliseconds, it's just going to cut the volume out whenever the tape is too slow (you can change that threshold as you like).  In my personal opinion, solutions like these are desirable because it's one less thing that can go wrong in terms of control-rate timing, which is always where the greatest variance seems to happen, especially as patches grow complex.  Plus, it's probably at least as efficient as using line~ and might even be more so. 


Thanks Peter to care and bring some quite useful commentaries ! I love this solution. That's quite elegant. What did you intend to do with the [s ---BufferLoaded] ?

To get an idea of the time to go from a speed of 0.1 and 0, I inserted a [timer] in you [p AutoTurnOff], but it doesn't work.

I guess that ime is 1/10 of the slowdown duration, as the speed decrease is linear, but wanted to check that.

Thanks Peter to care and bring some quite useful commentaries ! I love this solution. That's quite elegant. What did you intend to do with the [s ---BufferLoaded] ?
To get an idea of the time to go from a speed of 0.1 and 0, I inserted a [timer] in you [p AutoTurnOff], but it doesn't work.
I guess that ime is 1/10 of the slowdown duration, as the speed decrease is linear, but wanted to check that.


Happy to help. s ---BufferLoaded is vestigial, from an earlier iteration where I was looking at delta on the sync outlet of groove~, and I was calculating what the appropriate delta should be. That was a pain, and didn't work nearly as well as the next iteration (the one I posted).

Also, note that the time for slide~ to reach 0 is in fact longer than it looks (it is theoretically infinite and asymptotically approaching 0, but it ends up close enough that it does reach 0. Slide~ is similar to what's termed an RC circuit, and the timing of them is a little tricky. (in essence, they always move slower than the coefficient suggests; e.g. if you used slide~ 44100 44100, and the input switched from 0 to 1, the envelope should be at ~0.632 (not 1!) by one second after the change. More here: 

http://www.kvraudio.com/forum/printview.php?t=330148&start=0

In practice, for short transitions, it doesn't matter all that much. I suspect you'll be able to find some combination of cutoff speed and transition time that will work for almost everything.

Happy to help.  s ---BufferLoaded is vestigial, from an earlier iteration where I was looking at delta on the sync outlet of groove~, and I was calculating what the appropriate delta should be.  That was a pain, and didn't work nearly as well as the next iteration (the one I posted).

Also, note that the time for slide~ to reach 0 is in fact longer than it looks (it is theoretically infinite and asymptotically approaching 0, but it ends up close enough that it does reach 0.  Slide~ is similar to what's termed an RC circuit, and the timing of them is a little tricky.  (in essence, they always move slower than the coefficient suggests; e.g. if you used slide~ 44100 44100, and the input switched from 0 to 1, the envelope should be at ~0.632 (not 1!) by one second after the change.  More here: http://www.kvraudio.com/forum/printview.php?t=330148&start=0

In practice, for short transitions, it doesn't matter all that much.  I suspect you'll be able to find some combination of cutoff speed and transition time that will work for almost everything.


Ahah : 'impedance mismatch' remark ! I'm surprised there was no commentary in the max window about it !

About the fade : wouldn't [curve~] do the job ?

Ahah : 'impedance mismatch' remark ! I'm surprised there was no commentary in the max window about it !
About the fade : wouldn't [curve~] do the job ?


You could, but then you're back in control-rate domain with all the concomitant timing issues. (I'm assuming that you're talking about doing the volume ducking with curve~; pardon if otherwise)

My general rule of thumb is that anything that has to change rapidly and precisely should be done at signal-rate, unless a control-rate solution meets both of the prior requirements. It sometimes requires a bit more effort/CPU (though there are ways of reducing that via downsampling), but a lot of synchronization problems disappear.

You could, but then you're back in control-rate domain with all the concomitant timing issues.  (I'm assuming that you're talking about doing the volume ducking with curve~; pardon if otherwise)

My general rule of thumb is that anything that has to change rapidly and precisely should be done at signal-rate, unless a control-rate solution meets both of the prior requirements.  It sometimes requires a bit more effort/CPU (though there are ways of reducing that via downsampling), but a lot of synchronization problems disappear.


I work on a different take about this. I want it to play from a continuously recording buffer using [play~] object. For now, the Stop command is ok (eheh, that was easy) but I can't get the Start command to work. I think that once this will be the case, I'll just reorder the values from the list output by [curve~] for Stop, so I've let that aside until now. But I may also decide to add an envelope to allow it to be different from the satrting one. Here's what I've got for now :

I put up a simulation of an old varispeed tapedeck here awhile back that might be of interest - though it doesn't handle very low speeds well - it has an advanced section where you can adjust the motor on off speed etc.....I believe I used line in combination with a low pass filter to make an s curve?

https://cycling74.com/project/phonogene-1-2/

tapestart emulation