search

reckoner165 / SwarSequencer

A sequencer that enables tonal improvisation over 163 Indian Sampurna Ragas
6 stars 1 forks source link

Feature checklist #7

Open reckoner165 opened 5 years ago

reckoner165 commented 5 years ago

Tracking list of features required to make a minimum viable prototype

cc @amoghpj

amoghpj commented 5 years ago

Unclear about 3, and 4 needs some definitions.

  1. Add drone aka tanpura.
  2. Adding rudimentary taals, add rhythm cycles. Related to 3?
  3. Add parameters for gamak-iness, and some measure of "complexity" of a melody? These need further thought.
reckoner165 commented 5 years ago

Tanpura might be a challenging addition since the synthesizer resets every time cycle, making it hard to play drones.

Rudimentary taals would be useful to implement. I think those should be encoded as a dict that you can call from, and manipulate the string/list of notes as a part of improvisation.

Which brings me to a more fundamental issue - we need a (note, time, duration) representation that the REPL can understand and pass to sound module. We could mimic the MIDI standard, or make something more convenient for the time being.

amoghpj commented 5 years ago

To be honest, I do not understand enough about how things are currently represented. Is there a good reference for the MIDI standard? Is there a convenient western music notation that can be codified? If not, we can use a askshar-vibhaag- avartan scheme per taal that I have used in https://github.com/amoghpj/taal-encoding. Check out line 62 onwards. Let me know if this is relevant.

reckoner165 commented 5 years ago

https://github.com/amoghpj/taal-encoding/blob/master/taal_and_tukuda.py#L62 yup this is great! There are a few missing pieces before I can adopt your parser: The REPL can take in a list of notes (incl. silence). Is there a way to return the encoded taal as a list of notes&silences? This doesn't need to have an exact note. It can be a list of 0,1 too.

The sequencer can then take the note_list and taal_list and zip them into a 1-1 map, and then play each note in a list in line with the beat emphases. The rate at which you run through the list would be controlled using a global duration or BPM variable that's already there.

I'd love this to look like TIDAL (a la [n [n n] ~ [~ n]] where n is an arbitrary note), but I'm open to other ideas.

amoghpj commented 5 years ago

The conventional notation to separate an matra is a space and to separate vibhaags is a |. A sustain is usually encoded by an avagraha, which I represent using an S. I think it is a good idea to use a ~ to denote a silence which I don't have right now. I might also consider replacing the S with something that doesn't clash with the shadja. We can use the TIDAL notation to group a matra in [ ]. So selecting roopak will return [o] [n] [n] | [x] [n] | [x] [n], and we can use this as a kind of a template to expand a list of swars and assign them to each matra. I am not sure how the user can control the grouping within each matra though. That said, I like your idea of a taal_list where the user will input a free form string (say dha dhinatirakita dhinatirakita | dhin dhaghe | dhin dhaghe ||), which the bolParser will parse and assign to a taal and get the vibhaags. For this example the density of notes will be [1] [[2] [4]] [[2] [4]] | [1] [2] | [1] [2]||. The user will also specify a raag and the aaroha/avaroha as a parameter, which will generate the notes and are combined with the taal list.

Did I understand this correctly?