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

!