diff options
| -rw-r--r-- | README.md | 35 |
1 files changed, 22 insertions, 13 deletions
@@ -87,22 +87,31 @@ to do so should know the following about the IV files: from working properly. In addition, it should be noted that the clients are *designed* to overwrite one incoming note with the next, regardless of whether or not this interrupts the duration of the previous one--this is how "live mode" and "silence" work. +- Note streams *should* be sorted in priority order, most important first. In + practice, `mkiv.py` sorts them in order of descending duty cycle--the ratio + of time for which a note is playing to the duration of the performance--which + seems to be a good rule of thumb. `broadcast.py` allocates streams in the + order found in the interval file, so any streams which cannot be allocated + are culled from the end. (For testing purposes, polyphony is supported in the + Python client, which can artificially expand the number of clients at the + expense of volume, processing time, and quality.) # Todo -- Polyphony--have multiple voices on one machine - - Mixed polyphony: the audio is the result of mixing (saturating addition, etc.)--only doable with PCM - - LFO polyphony: tones are "rapidly" switched between (how old microcomputers used to accomplish this with one beep speaker) -- Preloading--send events to clients early to avoid jitter problems with the network +- [x] ~~Polyphony--have multiple voices on one machine~~ `-n` option to `client.py` + - [x] ~~Mixed polyphony: the audio is the result of mixing (saturating addition, etc.)--only doable with PCM~~ (current implementation in `client.py`) + - [x] ~~LFO polyphony: tones are "rapidly" switched between (how old microcomputers used to accomplish this with one beep speaker)~~ (this can be done at the interval level--see `downsamp.py`, which processes an `.iv` file into a `.downsamp.iv` file with only one stream which modulates between all active voices. At present, it only supports downsampling to one stream.) +- [ ] Preloading--send events to clients early to avoid jitter problems with the network - Would require a network time synchronization to work effectively; makes the broadcaster have less control over nuanced timing -- Other stream types--e.g., PCM streams for raw audio data - - More clientside implementation work - - Definitely a higher bandwidth--might interfere with critical timing, and would almost certainly need preloading -- Percussion--implement percussive instruments - - Requires an analysis of how current DAWs and MIDI editors mark "percussion" tracks--with a program change? GM specifies channel 10... -- Soundfonts--have the ability to significantly affect the instrumentation of the clients + - In practice, this is unnecessary with good network design principles; a decently under-capacity 1Gb network and good switches are more than enough to deliver 36-byte UDP packets in a timely fashion +- [x] ~~Other stream types--e.g., PCM streams for raw audio data~~ PCM is supported in `client.py` using the PCM packet type, and `broadcast.py` can play WAV files that are S16/44.1kHz, including a streaming WAV from (e.g.) `arecord` using the `--pcm` mode. + - ~~More clientside implementation work~~ + - ~~Definitely a higher bandwidth--might interfere with critical timing, and would almost certainly need preloading~~ `--pcm-lead` (clock drift is still an issue). +- [x] ~~Percussion--implement percussive instruments~~ `drums.py` is the reference implementation, and is actually more flexible--it can play any patch in response to any frequency command. + - ~~Requires an analysis of how current DAWs and MIDI editors mark "percussion" tracks--with a program change? GM specifies channel 10...~~ (that shows up as 9 in a zero-based channel count, by the way) +- [ ] Soundfonts--have the ability to significantly affect the instrumentation of the clients - Would also be nice to do this from the broadcaster's end without introducing RCE - Might require integration of another large libary like fluidsynth--at which point this would just be "networked MIDI" :) -- Code cleanup--make the entire project slightly more modular and palatable -- Graphics--display pretty things on machines with the capability - - Probably via pygame... +- [ ] Code cleanup--make the entire project slightly more modular and palatable +- [x] ~~Graphics--display pretty things on machines with the capability~~ Use `-G pygame_notes` with client.py, `-G pygame` with broadcast.py. + - ~~Probably via pygame...~~ (as implied by the names above, both *do* require pygame.) |