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...
- 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.
- what object to use for playback (tableplay~, xgroove~...) ???
Normally I prefer xgroove~.
- 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__