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__