[PD] help on random samplePlayer

[Frank Barknecht]

Hi,

Andre Schmidt hat gesagt: // Andre Schmidt wrote:

> i tested pecycle and it's VERY cool, i love it !!! 

Thank you VERY much. Glad to hear, you like it. But of course there's
room to improve it.

> (but too high for my newbie brain to modify/understand it :)...

Uhm, it's a bit confusing - but my desk looks worse ;)

> didn't quite understand if you played the audio-slices from one
> array/table or was every slice played from its own array/table... 

There are four main parts organiszed in subpatches which do different 
jobs. The flow is as follows: 

a) [pd readfile]
This is just a souped up openpanel->soundfiler->xgroove and is used to
fill the global array "loop" with the loop file. the readfile xgroove
then plays the loop and generates a position value that's read by a
snapshot~ for later use.

b) [pd analysis]
Here's where the search for percussion points with bonk~ happens. If
you remove all the control stuff, routing of learn and other messages,
it is basically just the bonk~ that sends out numbers for each
percussion part it finds in the signal coming in from [pd readfile]

c) [pd writer]
The snapshot~ values then get written into an array, the table
"$0-writer", at the positions that are given by the numbers sent by
bonk~. This happens in [pd writer].

We now have pairs in the array $0-writer, that describe which
instrument (y-axis) occurs at which loop file position (x-axis). 
$0-writer has the same length as the loop file. Where there is no
percussion instrument found, the table will have a value of 0. 

d) [pd player]
This is the ugliest part in pecycle and desparatly needs refacturing.
It has 9 arrays that take 9 splits of the same configurable length. 

The subpatch fullfills two tasks: First it fills the 9 arrays with
split parts from the main "loop". I use a tabwrite~ object for this.
The tabwrite~ reads what another xgroove~ is playing. This other
xgroove~ also has a position outlet that is watched by the 
[tabread~ $0-writer]. You remeber, that $0-writer holds the positions at
which instrument boundaries were found. tabread~ will then send zeros
most of the time, but at boundaries it will send 1, 2, 5, ...

These values get read by a snapshot~ and with a [select 1 2 3 ...]
they are used to change the name of the array, that the tabwrite~ from
above writes to accordingly. 

Now we have short splits of the main loop in the 9 arrays that
all start with a percussive sound.

The rest is ugly but easy: A metro bangs regularily on a [random]
object. The resulting number is used to set the array used of a final
tabplay~ that plays what comes out of your speakers. 

> as i am now seriously planning this project, here are some questions
> that i need as corner stones before i start my journey...
> 
> 1. table/array is THE way to store audiosamples for playback ???

You can also play files directly from disk with readsf~, but this
might give short breaks at the looppoints, so I used tables.

> 2. what object to use for playback (tableplay~, xgroove~...) ???

Normally I prefer xgroove~. 

> 3. performance difference between playing audioslices from their own tables
> or jumping to slicepoints in 1 array/table ??? (i would prefer jumping in 1
> table)

Although I normally prefer xgroove~, I didn't use it here ...
> i managed to get my idea 2 work with 1table and xgroove~. but when i jump
> with "pos" in xgroove~ from point Y to point X i hear clicks. 
... because I also got this behaviour. 

> i think i know why the clicks come (the position of the sample in
> the end of Y is not same as in start of X), but i'm too newbie to
> know how to eliminate them...

You can try to declick it with a line~ object. In fact, I also needed
to declick the last tabplay~ in my pecycle mini-app, so maybe I could
have used xgroove~ here as well. 

ciao,
-- 
 Frank Barknecht                               _ ______footils.org__