Alan Joesbury

I know it's a horrible title, but there's no easy way to explain my problem in one sentence.

Part of my patch is seven samples triggered by an infra red sensor connected to an Arduino board.

If you take a look at the part of my patch I've 'copy compressed' below it will be easier to explain.

I have incoming values scaled to 12 (ignore that I'm only currently using 7 samples) and when I trigger the samples by moving my hand towards and away from the infra red sensor, the same sample can be triggered very easily straight after itself - making it interrupt itself without playing all the way through (each sample is only maybe 3 - 4 seconds long anyway).

I have tried [onebang] and looked at [snapshot~] and [gate] as they've been suggested in another thread (

https://cycling74.com/forums/maxmsp-help-for-new-user-senors-to-trigger-audio-files)

Also, notice after my 'bangs' I have 0, 10000 10000

The help for [line~] tells me that "A common way to generate a ramp: set initial value followed by list with new value and target time".

I don't understand this, I only understand that the second and third values need to be long enough to play the complete sample if I want the complete sample to be heard. Can this be explained please?

My max knowledge is limited, I hope I don't bore the forum with questions over the next few weeks.

Part of my patch is seven samples triggered by an infra red sensor connected to an Arduino board.
If you take a look at the part of my patch I've 'copy compressed' below it will be easier to explain.

I have incoming values scaled to 12 (ignore that I'm only currently using 7 samples) and when I trigger the samples by moving my hand towards and away from the infra red sensor, the same sample can be triggered very easily straight after itself - making it interrupt itself without playing all the way through (each sample is only maybe 3 - 4 seconds long anyway).
Is there a way around this?

I have tried [onebang] and looked at [snapshot~] and [gate] as they've been suggested in another thread (https://cycling74.com/forums/maxmsp-help-for-new-user-senors-to-trigger-audio-files) however non have solved the problem.

Also, notice after my 'bangs' I have 0, 10000 10000
The help for [line~] tells me that "A common way to generate a ramp: set initial value followed by list with new value and target time".
I don't understand this, I only understand that the second and third values need to be long enough to play the complete sample if I want the complete sample to be heard. Can this be explained please?

My max knowledge is limited, I hope I don't bore the forum with questions over the next few weeks.
Thanks for any help,

allow-sample-to-play-uninterrupted-by-itself

have a look at this. by using the right outlet of line~ you can reset the onebang once the soundfile has finished playing. Also, by using info~ you can set the exact length of the soundfile for the line~.

Those three numbers "0, 10000 10000" do the following:

the first resets the line~ to 0, the second tells line how far to go and the last one tells it how long to take to get to the second value. so in this case, line starts at 0 and will go to 10000 in 10000 msec. For original soundfile playback you will want to have something like "0, filelength filelength" meaning that you are starting at the beginning of the file and go to the end of the file in the amount of time the file is long.

have a look at this. by using the right outlet of line~ you can reset the onebang once the soundfile has finished playing. Also, by using info~ you can set the exact length of the soundfile for the line~.
Those three numbers "0, 10000 10000" do the following:
the first resets the line~ to 0, the second tells line how far to go and the last one tells it how long to take to get to the second value. so in this case, line starts at 0 and will go to 10000 in 10000 msec. For original soundfile playback you will want to have something like "0, filelength filelength" meaning that you are starting at the beginning of the file and go to the end of the file in the amount of time the file is long. 

The problem of having interrupted samples with lots of clicking has gone.

I'm thinking it may be an idea to make my samples even shorter now, because if I trigger them all very quickly they all have to complete before they'll play again. I can't have everything anyway, and having samples play in their entirety is much more important to me than

Also, what you've done with my old '0, 10000 10000', have you set it to 'autofill' from the file so that I do not have to enter a value manually?

That's brilliant MIB, thank you.
The problem of having interrupted samples with lots of clicking has gone.

I'm thinking it may be an idea to make my samples even shorter now, because if I trigger them all very quickly they all have to complete before they'll play again. I can't have everything anyway, and having samples play in their entirety is much more important to me than 

Also, what you've done with my old '0, 10000 10000', have you set it to 'autofill' from the file so that I do not have to enter a value manually?
Cheers for your help MIB.


A method of removing clicks from interrupted samples would involve using a second [line~] object to create an amplitude ramp that is triggered when the sample is re-triggered.

If you use this in conjunction with the method MIB suggested for controlling the minimum amount of sample playback before re-triggering is permitted, cicks should be eliminated.

A method of removing clicks from interrupted samples would involve using a second [line~] object to create an amplitude ramp that is triggered when the sample is re-triggered. 

If you use this in conjunction with the method MIB suggested for controlling the minimum amount of sample playback before re-triggering is permitted, cicks should be eliminated.


Allow sample to play uninterrupted by itself.