-
Notifications
You must be signed in to change notification settings - Fork 3
What should be in BeatLounge and what should be extension?
- Scheduler (yes)
- Instruments
- sf2
- samples (TBD)
- synthesizer (TBD)
- Rudiments
- Arps
- MIDI
What about music? Should we just establish a whole library of exotic math and constants? Anything goes under bl.music?
[I don't like "anything goes" development :-). There's code review. Anything goes in a branch of course. And then if it's something you're intent on putting it in master, do merge request. And someone will review and decide if it needs more work or is simply out of the scope. But really, to start the process, tickets are nice--they allow for some up front design discussion to decide whether or not said feature really belongs in bl, etc.]
at a certain namespace, we should allow almost anything under say
bl.music.structures
for weird stuff like grasshoppers.
[How about "bl.music.sandbox" or "bl.music.contrib"? I still would say it should be subject to code review (though slightly less rigorous code review, whatever that means) and tests are still important. Some of the concepts that develop there could become important pieces of code that eventually get generalized into something else.]
[Also, in general, I think bl.music should really be simplified. I don't think we need special objects for notes for both simplicity and efficiency reasons. The original "array of" integers approach might be good enough for describing 12TET - e.g. C = [0, 12, 24, ]. Beyond being essentially a database of notes, scales and a few functions for doing inversions etc, I'm not sure if it needs to really be much else.]
Hrm, there are all of the Ragas and Talas potentially and that is just one
culture. I don't want to limit it to just midi integers.
bl.music.structures
or bl.music.db
.
[I don't want to limit it to 12TET either. Notes are just constants, you don't have to use those and might use radically different values or even types for a different instrument implementation. I do want to have constants for 12TET though and the module should maybe be called bl.music.midinotes. The reality is MIDI is designed around 12TET, and most people will just want 12TET. The only really stable backend we have now, fluidsynth, also expects midi notes. I also want other tonal systems, but I'd rather first have a good backend to support that. There's nothing in the instrument interface that demands 12TET MIDI values so I don't think we've at all painted or will paint ourselves into a corner with 12TET. None of the other modules in BL should import anything from bl.music anyhow.]
[Does this mean part of beatlounge project, or a separate project that uses bl as dependency?]
I mean, not in the beatlounge repository but bl as a dependency.
[cool]
- webservers / htmljs apps ?
- but, if not in core, needs to be an easy path to make [clients (htmljs for instance) that can talk to the bl]
- DSLs, custom shells. I'm thinking of some DSL for designing and scheduling arps, rudiments, etc. This would be awesome since you make a more secure environment (web-based or whatever) for collaborative live coding.
[what do you mean by "make"?]
"make" I mean quickly produce services that can make the beatlounge schedule stuff and play sounds. Like an http api for instance.
[Ah, yes. I think there should be different modes for doing this, maybe. The preferred mode I think should be make beatlounge a service (I'll open a ticket for this), and this can be made one service in a MultiService for a twisted.web application, for example. Maybe a second option would be to have some convenience API for people who don't want to build with Twisted--some kind of convenience API for running beatlounge daemon or sth. This second option is not so appealing to me, though.]