Mattia Zanzi

Hi there! Is it possible to offset (i.e. to slide) a sample within a buffer~ or waveform~ window? See the picture below: I'd like to have the possibility to move that sample in time by a value N; if N = 1000, I'd like to see the sample onset sliding to the 1000 bar. However, I don't want the time bars to move when offsetting, but just the sample (i.e. I want to always keep the waveform~ window starting from zero). Thanks!

Schermata 2021-09-17 alle 10.53.46.png

Hi there! Is it possible to offset (i.e. to slide) a sample within a  buffer~ or waveform~ window? See the picture below: I'd like to have the possibility to move that sample in time by a value N; if N = 1000, I'd like to see the sample onset sliding to the 1000 bar. However, I don't want the time bars to move when offsetting, but just the sample (i.e. I  want to always keep the waveform~ window starting from zero). Thanks!

Hi there! Is it possible to offset (i.e. to slide) a sample within a  buffer~ or waveform~ window? See the picture below: I'd like to have t

sample-offset-in-a-buffer

you wil have to use some buffer~ manipulation external or mxj.

there is BufOp java class in max included,

or one can try eric lyons el.buffet object, or simply peek~ to

move audio in the buffer to offset location.

you wil have to use  some buffer~  manipulation external or mxj.
there is BufOp java class in max included,
or one can try eric lyons el.buffet object, or simply peek~ to
move audio in the buffer to offset location.


Thanks for replying. Do you have any advice on how to use the peek~ object in this context?

peek~ will probably not be the fastest and most efficient way to do what you want.

You simply use one peek~ to read the current buffer,

and another one to write output of the first one into same buffer, but

At the end, you wipe the first 1000 ms of the buffer.

That will work only if buffer~ has extra free 1000 ms to move the sample.

Populating the buffer using replace message will fail for that.

peek~ will probably not be the fastest and most efficient way to do what you want.
But if you want to try it, why not.
You simply use one peek~ to read the current buffer,
and another one to write output of the first one into same buffer, but
offset by 1000 ms, expressed in samples.
At the end, you wipe the first 1000 ms of the buffer.
That will work only if buffer~ has extra free 1000 ms to move the sample.
Populating the buffer using replace message will fail for that.


Thanks for your example and, more generally, your help !

I got 2 more questions, if you don't mind:

1./ How do you make your patch for incoming audio instead of counters (I'm kind of confused, I'm having trouble converting :/ ) 

2./ How do you do this in gen~ ? I struggle to find examples...

Hi Source Audio ! 
Thanks for your example and, more generally, your help !

I got 2 more questions, if you don't mind:

 1./ How do you make your patch for incoming audio instead of counters (I'm kind of confused, I'm having trouble converting :/ )  

2./ How do you do this in gen~ ? I struggle to find examples...

1- I don't understand the point - incoming audio.

Record something , after recording shift or offset audio into different buffer ?

Or simply record audio to some later time point in buffer instead of 0 ?

1-  I don't understand the point - incoming audio.
Means you want to do what ?
Record something , after recording  shift or offset audio into different buffer ?
Or simply record audio to some later time point in buffer instead of 0 ?

i think for what you want to do you dont even need to manipulate the actual data in the buffer.

you simply have to make the buffer somewhat bigger than required for the content, place your content in the middle instead of at the beginning, and then create yourself an interface where the position "0." (for example when recording and replaying) ends up starting the sample with an offset to that position where it actually is.

the same can then be done with the waveform~ display, just remap 0 to 1000 or whatever you need to see what you want to see. it is all only a matter of interpretation.


i think for what you want to do you dont even need to manipulate the actual data in the buffer.

you simply have to make the buffer somewhat bigger than required for the content, place your content in the middle instead of at the beginning, and then create yourself an interface where the position "0." (for example when recording and replaying) ends up starting the sample with an offset to that position where it actually is.

the same can then be done with the waveform~ display, just remap 0 to 1000 or whatever you need to see what you want to see. it is all only a matter of interpretation.


I forgot to mention, I would like to adapt this for a max for live device... I'm currently handling the offset moving the grid but I would like to offset the display of my incoming audio directly. From what I understand your example only works with loaded files, but in my case, incoming audio is recorded (sent to the waveform~) and overwrited from the beginning each time the buffer size is filled (it loops to let me visualize the incoming signal).

I actually want to record incoming audio then shift the content to an earlier time point. I'm routing audio from another track, this signal is a bit late to the party, I would like to find a way to offset his representation to an earlier point to make it start at 0 on waveform~ (instead of modifying the grid position).

Sorry if I'm not so clear, I try my best to explain myself with my poor vocabulary :)

1-  I don't understand the point - incoming audio. Means you want to do what ?

Record something , after recording  shift or offset audio into different buffer ? Or simply record audio to some later time point in buffer instead of 0 ?

I actually want to record incoming audio then shift the content to an earlier time point. I'm routing audio from another track, this signal is a bit late to the party, I would like to find a way to offset his representation to an earlier point to make it start at 0 on waveform~ (instead of modifying the grid position).

Sorry if I'm not so clear, I try my best to explain myself with my poor vocabulary :)

I thought about this solution and I think it's an interesting one. I'll probably do this if I don't find another way.

i think for what you want to do you dont even need to manipulate the actual data in the buffer.  you simply have to make the buffer somewhat bigger than required for the content, place your content in the middle instead of at the beginning, and then create yourself an interface where the position "0." (for example when recording and replaying) ends up starting the sample with an offset to that position where it actually is.  the same can then be done with the waveform~ display, just remap 0 to 1000 or whatever you need to see what you want to see. it is all only a matter of interpretation.

Thanks for your answer !
I thought about this solution and I think it's an interesting one. I'll probably do this if I don't find another way.

1- do you want to compensate the latency from original track and recorded audio track ?

2- or only to do so for waveform display ?

To do the first, you can start recording delayed by latency ammount,

Depending on what you use to record, one could shift

but using any buffer manipulation is totally wrong,

because that reorders samples once, and you need

here is example taking that audio has 100 ms latency.

inserting 100 ms pipe to start recording later aligns the play - rec buffers

latency.mov

I still don't understand one thing.
1-  do you want to compensate the latency from original track and recorded audio track ?
2- or only to do so for waveform display ?

To do the first, you can start recording delayed by latency ammount,
which I trust would be constant.
Depending on what you use to record, one could shift
samplecount for count~ poke~ combo 
and so on.

but using any buffer manipulation is totally wrong,
because that reorders samples once, and you need
real time stream.
here is example taking that audio has 100 ms latency.
inserting 100 ms pipe to start recording later aligns the play - rec buffers


It's just a matter of visualization here, all I need is a way to "move" content earlier in waveform~. 

A way to compensate latency it would be very interesting for other applications ! By the way, is there a way to know the actual latency of a signal ? I mean, my incoming audio is delayed by 17ms, is this a constant caused by Live internal routing or it depends on PC specs ?

If I understand well, I'll need a second buffer to record the 1rst one (a bit delayed). 

I guess, with this solution, the waveform~ display will be delayed by the amount of delay used to trigger the recording on the 2nd buffer.

Hi @Source Audio !

It's just a matter of visualization here, all I need is a way to "move" content earlier in waveform~. 
A way to compensate latency it would be very interesting for other applications ! By the way, is there a way to know the actual latency of a signal ? I mean, my incoming audio is delayed by 17ms, is this a constant caused by Live internal routing or it depends on PC specs ?

If I understand well, I'll need a second buffer to record the 1rst one (a bit delayed). 
I guess, with this solution, the waveform~ display will be delayed by the amount of delay used to trigger the recording on the 2nd buffer. 

It's just a matter of visualization here, all I need is a way to "move" content earlier in waveform~. A way to compensate latency it would be very interesting for other applications ! By the way, is there a way to know the actual latency of a signal ? I mean, my incoming audio is delayed by 17ms, is this a constant caused by Live internal routing or it depends on PC specs ? 

If I understand well, I'll need a second buffer to record the 1rst one (a bit delayed). I guess, with this solution, the waveform~ display will be delayed by the amount of delay used to trigger the recording on the 2nd buffer.

Hi @Source Audio !  

It's just a matter of visualization here, all I need is a way to "move" content earlier in waveform~.  A way to compensate latency it would be very interesting for other applications ! By the way, is there a way to know the actual latency of a signal ? I mean, my incoming audio is delayed by 17ms, is this a constant caused by Live internal routing or it depends on PC specs ?  

If I understand well, I'll need a second buffer to record the 1rst one (a bit delayed).  I guess, with this solution, the waveform~ display will be delayed by the amount of delay used to trigger the recording on the 2nd buffer. 

In Max one measures latency by sending short pulse out and record it back, measure time .

there is latency-test.maxpat in examples that can be used for that.

I don't have any idea about live latency between tracks, what if/when plugins are inserted,

means how good latency compensation for plugins is etc.

For hardware and in Max, latency is constant and depends on Max side on

vector sizes set in audio setup, on hardware side the drivers, ADC DAC chips etc.

I don't kow how you record your tracks, using delayed start/stop can be option,

much tighter would be sample count with set offset,

but I can't tell you how to do that in Live, maybe locked phasor~ 

here few things to look at, you will recognise what it does

taken sample rate 44100, latency 17 ms, 4 bars loop

Screen Shot 2022-04-15 at 12.52.10.png

Also be prepared to loose portion of audio in recorded track,

because recording will stop immediately when live transport stops.

Also - no idea what happens with relation Live tempo changes - bar length in samples

I am not Live user at all.
In Max one measures latency by sending short pulse out and record it back, measure time .
there is latency-test.maxpat in examples that can be used for that.

I don't have any idea about live latency between tracks, what if/when plugins are inserted,
means how good latency compensation for plugins is etc.

For hardware and in Max, latency is constant and depends on Max side on
vector sizes set in audio setup, on hardware side the drivers, ADC DAC chips etc.
------------
I don't kow how you record your tracks, using delayed start/stop can be option,
much tighter would be sample count with set offset,
but I can't tell you how to do that in Live, maybe locked phasor~ 
here few things to look at, you will recognise what it does
taken sample rate 44100, latency 17 ms,  4 bars loop



Also be prepared to loose portion of audio in recorded track,
because recording will stop immediately when live transport stops.
Also - no idea what happens with relation Live tempo changes  - bar length in samples
etc etc I am not using Live


example.amxd

Oh sorry I sent you the M4L device before I saw your comment !

Sample offset in a buffer