Hey!

i've been searching for ways to generate envelopes algorithmically and store them in arrays, and couldn't manage to find what i was looking for, so decided to go on by myself and ended up with this...

Hopefully, this can be usefull for someone else!

http://www.pdpatchrepo.info/hurleur/array_ASR.pd

I built a subpatch for timestretching based on the phase vocoder example in the pd browser documentation.

It contains a block~ object which gets a message with the window size for the fft analysis.

When i try to switch off the subpatch using switch~ and a toggle it seems like it does'nt work. I guess there is some kind of interference between block~and switch~that i didn't manage to understand.

I was wondering if forcing block~ to compute 0 sample length blocks with |set 0( was equal to switch off dsp...

?

Hi Again!

i have found a problem which is driving me crazy...
i must admit i am a total noob on dsp and maybe the solution is just in front of my face... but i can't find it, so came here claiming for some help

The question is related to a phasor.
i am using it as an index scanner for a tabread~, to read a sample,
so i'm multiplying the output of the phasor by the size of the chunk i want to play, and updating the phasor's frequency depending on this chunk's size.

[hz~\ (related to chunksize)
|
|
[phasor~]
|
| [chunksize~\
| |
| |
[*~]
|
|
.
.
[tabread~]

Everything fine to this point.

but everytime i do a chunk size / frequency change the "header" is (obviously) doing a jump, as it is being multiplied by a different number.

I would preffer the header to "keep where it is" and go on until the end of the (new) chunk.
Note that i don't want to wait until previous chunk is finished, but immediately change size and frequency settings (so the samphold~ approach referenced in the tutorials is not usefull for me)

Is there any way to achieve this, and keep using the phasor~ approach?
maybe there is some object around that i am missing...

i'm attaching a simple reproduction of this problem

Thank you!!!!

http://www.pdpatchrepo.info/hurleur/phasor_jump.pd

So i managed to recreate a delay behaviour using tabwrite~ and tabread4~.

Tha main reason for using this objects instead of delread~/delwrite~ is that i need to "freeze" the buffer content from time to time (stop feeding it with new samples), and add chunks of new data into the array again after stopping some time ( haven't tried this yet, but it looks like this is possible by sending |start n( to tabwrite~ )

i've also seen a great solution for doing delays using tables by means of poke~, but i can't use this object as i need to be limited to vanilla for ofxpd integration purposes.

But now, i'm facing 2 problems:

1- in order to write and read simultaneoulsy the same table, the read header has to be slightly delayed to make sure it is reading data that has already been written. I accomplished this by adjusting phase of the phasor~ object with a message to the right inlet. I guess this is not the more accurate solution.... any hints on that?

2- I get a click at every end of the "loop"... how can i smooth that? maybe fading in/out at every start/end of the table writing?

I attach the actual patch, so you can see for yourself.

Thanks!

http://www.pdpatchrepo.info/hurleur/tabread_delay.pd

hello!

i've been messing around with puredata for some time now, mainly for interactive and arduino stuff. Now i am facing a much bigger project, and need some help to start with it...

basically, what i need to do is a live_sampling/realtime_fx engine which allow me to do the following:

-store audio data coming from adc into an array and play it at the same time
-freely moving play-header through the buffer withouth doppler artifacts
-granular stuff in realtime (mainly granular timestretching and the like)
-"freeze" the stored buffer and start playing it (also in granular flavour), stoping the audio input in the array
-multiply number of playheads (maybe this is something related with voices?)

and all this, if possible, using just vanilla objects, as it has to be used inside openframeworks by means of libpd and ofxpd...

We've been working on this project for a long time now, using different approaches. You can see some results here:

This was done some years ago using Reaktor's grain cloud delay, which was a very powerful and easy way of developing the audio side, but closed architecture and not able to integrate it in a single Ofx/C++ application, just OSC communication, so it's not an option anymore... now with ofxpd we can develop it in pure data and integrate it with openframeworks, which is very good!

I've been messing around with some examples i found on this forum, with partial nice results, so first steps are already done and got (kind of) familiarized with tabread~, tabwrite~, vd~, delread~, delwrite~...

I would like to ask if someone has been doing something similar, and can point me in the right direction?

thank you!

i've been doing this sort of granular timestretching in realtime, mainly for rhythmic materials.

In my case, i just scrubbed a window (grain) to the past slowly for some time (usually related with beat measures), then jumped back to realtime and started again…

Hey!

inspired by your post i also made an lfo including pow function.
I also made a processing sketch for visualization, managed by OpenSoundControl

i guess some optimization could be done,
but hope this is usefull!

http://www.pdpatchrepo.info/hurleur/LFODraw.zip

Good! it works like a charm!

Thanks again Maelstorm!

Hey Katjav! thanks for your reply and advices!

just tried the numberbox-between-toggle-and-switch~ trick and it's not working for me...

i'm not experiencing syncing problems (or at least i can't recognize them)... So my only concern is how to switch-off that subpatch, maybe using alternative methods to switch?

So, telling block~ to compute 0 sample blocks is equal to switch off DSP?
or does it at least lighten the CPU load?

change the loop boundaries without resetting the phase! yes!
i could have never explained it better!

[susloop~] looks exactly what i need

lots of thanks Maelstorm,
now i can go ahead with my patch

!

i think using [samphold~] is not usefull in my situation, as i want to immediately change the chunk size (and related frequency of the phasor), and keep the resulting read-index for the table in the same position it was before the chunk-size change, so it can go on without any noticeable jump...

at the end, what i want is to reproduce the behavior of a window-loop as the ones you can see in daw or video-editing software.... when you change the outpoint of the window the header is not jumping, but moving until the end of the new position.

i also tried with [loop~], but again it is updating chunk-size parametre ONLY when the header has arrived at the end of the previous end-point...

shit... this is difficult to explain....
and maybe i am misunderstanding something....

i'm not having much success with my last attached solution, as it is introducing some strange behavior and clicks when reading the contens of the table...

i guess the [delay 1] object and the [pd audiotocontrol] subpatch are doing a mess in the execution order of the messages, and making my patch to fail...

any ideas on how to make a better implementation of this proportional phase reset, in a propper way?

I just came with a possible solution for this issue, i guess coded badly...

The idea is to reset the phase of the phasor to a value proportional for the new length.

am i in the right direction? any ideas about this?

http://www.pdpatchrepo.info/hurleur/phasor_jump_2.pd

Hey Husk,
thanks for your help!

i moved some questions to this other post:

http://puredata.hurleur.com/sujet-8456-delay-using-tabread-tabwrite

and i managed to start everything... it looks like it's working now reasonably well,
i'm so happy about the libpd binding... sooo powerfull!

i'll keep you updated!

Thanks for your answers!

it's clean and working now... i will post results as soon it ends being a mess of boxes and cords...

i just came across the great collection of abstractions by rjdj
https://github.com/rjdj/rjlib

it looks like there's a bunch of patches on there tat can be a good starting point.
I specially liked the e_graindelread abstraction, which is basically a delay line with granular features and clickless variable delay time...

My main aim now is to figure out how to store the buffer content in a table at any moment... i think it is not possible out of the box using delwrite~, so i guess i'll have to do some kind of workaround...

by the way,
playmodes AV sampler project is on github, if you want to check it out:
https://github.com/eloimaduell/ofxPlaymodes