kitefishlabs / cbpsc Goto Github PK

They don't seem to reflect the actual API... e. g.

~crps.analyzeSoundFile(~testpath);

analyzeSoundFile has two non-optional arguments, which just lead to failed calls...

Is there some other help available somewhere which is more correct?

There should be an example of something fairly straight-forward that can demonstrate use of cbpsc without a GUI.

sync with CorpusDB

When running

~mycorpus.analyzeSoundFile(sfID: ~latest_index.sfID);

I get various errors of the type

*** ERROR: SynthDef xxxAnalyzerNRT not found

(xxx changes for different analysis SynthDefs :-) ).
Apparently those SynthDefs used to be defined in CorpusDB.sc up until commit 8254a5d (Nov 2012) but have been removed afterwards. I couldn't find them anywhere in the repository either.

Make sure that the various array-style access methods are implemented here.

Mirror CorpusDB...

Now: unitID, parentID (new), sfID, relID (reordered), procID (new), tag (reordered), onset, dur, transp (reordered)

This will allow for doing set operations on corpus units based on parent/child relationships, transpositions, tags, process IDs, etc.

Instead of CORPUSNAME.sfgmap, use CORPUSNAME.sftree.trackbacks

Just like "corpus" data can be provided as a 2D array, one should be able to access sound file data as one big array. (or possibly two arrays, one for SamplerNodes and one for EfxNodes).

Should be accessing sfile metadata for both SamplerNodes and EfxNodes via this pattern:

CORPUSNAME.sftree.trackbackType(sfid) and
CORPUSNAME.sftree.trackbackMetadata(sfid) ...

Document setup of KDTree and simple similarity table.

Include examples of:

• Subcorpora.
• Iteration + analysis.
• Access to raw metadata for automated segmentation.
• Import multiple corpora.

JSON file should not have to track outbus, inbus, etc. These should be silently added to params lists.

Use CORPUSNAME.sftree.trackbacks instead of CORPUSNAME.sfmap
(sfid -> [filepath, dur, transp, sampling UGen name] or
sfid -> [[synthdefs], [param-lists]]