The future of cl-patterns.
A list of the bigger changes and functionality planned for implementation, along with the approximate versions they’re intended for. For a longer list of tasks and ideas, see TODO.org.
tests for all patterns, event keys, clock, etc.
commit e73e3933b912326c2690fcf4260d9a648373539e and others
commit 163e86a6ffb82be31f15a563903e0b6ad362813a
commit a49a71542e5cf1b2226b5fc1e0a263bbf2e3315c
commit ebf7d158e01792844921a98c2a5e900d6405dc4d
commit ed10b6f7c8d86ccc62e28a465c7d75312cdbf9de commit d363c833b92320bf7c6293d2e3fa5b732be6e8c6 - condition-handler slot
commit 49f8dba18556434bd1b095fcd2c0b42b8bddcf78
commit b4fba7ed7c011287eeab8282c4d771478c3b923e
commit d384648c5e35cc64619c28b485b6a7a4b3e4a385
commit 2c0ab678bb5c9229194773f41fdedc16a08ad5dd
commit 49f8dba18556434bd1b095fcd2c0b42b8bddcf78
commit c7a2aac40417641f7a1fdb6d4cda20e48401dcdf
commit 98037572e37dd83c2bc8610b14543e3fb4301480
commit 77166dadf8bb70c77d80aea8d1323536561352a1
commit 2c0ab678bb5c9229194773f41fdedc16a08ad5dd
commit e3a142271a350582632007b6da2690ab005a67f0
commit 6006cd5adb3cdfa6ea4080f9e7904717044f442a and others
more shared/inherited functionality, i.e. make pbind
, pmeta
, etc. all use a common set of functions to process arguments.
basically objects that represent values (i.e. for pitch
, volume
, etc.) with units to make them easier to use in functions and keep track of what they represent/convert between them. any keys like freq
, midinote
, amp
, etc. should automatically create a quantity object internally and store it in the pattern or event’s pitch
, volume
, etc. key.
this should allow for cleaner code in various places, and both features will be less mentally taxing to use.
make each enabled backend its own object so it can have its own parameters rather than relying on global variables
events with quant
and latency
set to 0
should be able to play “immediately” with no quantization like what happens now
maybe the clock should “sleep” (end processing thread) when there are no tasks and automatically “wake up” when a task is added?
use internal-real-time instead? sbcl’s internal-time-units-per-second is 1000000 which is higher than even most “pro audio” sampling rates go, but other implementations may have less. last i checked 1000 was the norm; is it acceptable?
generalize how the clock handles tasks, i.e. method/function to return a list of events within a specific time range, separated from the function that processes said events to backends. perhaps using ipstream
.
maybe remove mono
event type and just implement some sort of monophony pattern that can be used as a filter/post-processing pattern?
implementation of most common/useful SuperCollider patterns (see sc.org)
cl-patterns-based digital audio workstation and live coding laboratory.
audio buffer abstraction with conveniences like auto-conversion, metadata, “splits”, etc.