dxinteractive / xenpaper Goto Github PK

This still allows for microtonality, while outsourcing opinions about the choice of root hz, and allows the sound engines that play mosc to perform glides without stretching before internally translating to hz if required

They're bland right now

Hello 👋.

I noticed that in some cases the character m in a comment triggers a parsing error. For example:

# Ptolemy's Diatonic Scales
{1/1 21/20 7/6 4/3 3/2 63/40 7/4}
0 1 2 3 4 5 6 7-

# Ptolemy's Tense Diatonic
{1/1 16/15 6/5 4/3 3/2 8/5 9/5}
0 1 2 3 4 5 6 7-

In this case, if the m is removed from the second instance of Ptolemy's, parsing succeeds.

This is an excellent app, and I have been enjoying it quite a lot. Thank you for making it! ❤️

The normal mobile keypad hakes up half the screen and many symbols are scattered through secondary panels. If the browser can toggle the keypad then it could show a numbers-and-common-symbols, and toggle the normal alphabet one when selection enters a setter or a scale.

Could use ~ instead of -. Could also add a setter to control width and rate and perhaps volume vs pitch variation of vibrato

Add a column to the left of the text area with Play and Loop buttons next to each line. The line with Play selected will be the one that the playhead starts from. If a Loop is selected, the end of the line with loop will loop back to the line with Play. Also include keyboard shortcuts, perhaps ctrl + , and ctrl + .

Sick of hitting "home" instead of the play button on mobile by mistake and losing my stuff :(

Often melodies will shift into another octave for a while. Current syntax is like

7,10,'0--..10|'2,'3,'2,'0,'2-10-|'0,10,5--..7|8,7,5,3,0-v10-

Lot of annoying consecutive ^. Setting the root can help, but is still bulkier than it could be

7,10,'0--..10|{r'0}2,3,2,0,2-v10-|{r`0}'0,10,5--..7|8,7,5,3,0-..

If we want to use up another symbol, e.g. a * could be used to latch and unlatch an octave. The symbol * doesn't particularly matter but must not be visually too big, preferably be in the top half of the char space so it looks more connected to the octave chars than the pitches or anything else

7,10,'0--..10|'*2,3,2,0,2-*10-|'0,10,5--..7|8,7,5,3,0-..

Where a * after an octave shift will retain it until another back tick is encountered

For example when you input
{40edo}[0]
and then erase that '4' to replace it with something else (50edo for ex.) it crashes besause of temporary {0edo}[0] (zero-edo) state

Another example:
(bpm:5){r200Hz}{4000edo} [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16] works perfectly, but
(bpm:5){r200Hz}{000edo} [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16] makes it crash again

Undo and redo currently only work for edits made directly into the textarea, but dendriform has its own history stack so should use that.

So play / pause and eventually perhaps seek can all be controlled without losing focus from main text area.

When using really long bpms (I typically use 1 or less...), the "stop" button won't stop the sound until the clock has run out on the beat! MIDI people are used to a "panic button" and something like that would be good here.
Other forms of setting the time like msecs:nnn or secs:nn would be nice too.

Wonder if anyone might want this. Allows a tune to be embedded in a very small iframe on external websites. Would be useful if anyone ever uses this thing in blog posts or explainers and wants tunes dispersed between text sections.

Now the sequences are manually written by user, this feature will allow to use arbitrary growing sequences (e.g. from OEIS) without breaking out of hearing range.

Example:
Ulam sequence under 100 taken from internet and taken modulo 13 in BP.

Somewhat ironically we can go anywhere in the pitch domain (unlike normal DAWs) but are restricted to a grid in the time domain.

• Rhythms defined similarly to scales could work very well!
• What about one off differences? Some kind of lightweight syntax to shift timing of individual notes a little bit?

Hi! I love this!
I have a question as a super-noob of webmidiapi or music in the browser.

Have you ever thought to permit the user to play multiple tracks simultaneously in xenpaper?

Is there a good reason not to put the code up publicly and under an appropriate license like AGPL?

Will need some thought, but not impossible.

• Will depend on current scale, which means that we really need a playhead that can be placed at a specific time so that the region of the tune to play in can be selected, so depends on #1
• Can have a default key mapping like Scale Workshop does. What about custom mappings?
• Can the played notes be easily entered into the tune? Actually recording timing may be overkill considering the abilities of this app (no metronome, rigid timing, latency), so perhaps a kind of console log that just keeps track of notes that were played.

Very minor bug

Really want this one but it's a bit of work. Tracks are their own note lanes that are played simultaneously

• Setters will need to be able to target individual tracks, or all
• Tracks should be nameable and referenceable
• Visually should format them like staves

Renew fees for the domain are more expensive than I thought, and links posted on most places hardly even show the domain name. Better remove reference to this before links become widespread (if they do at all)

• Sticky play button
• Smaller text

Plotting has now meant that there is more need to getting lots of notes out at once, and specific sequences of pitches that are a pain to type out manually.

Ideas

• arp, plays all notes in scale as an arpeggio
• all, plays all notes in scale at once for the sake of plotting them in the notes column
  • or do we just make the ruler be able to select which plot to compare against?
• 22::44, harmonic series segment
• 5limit, various odd limit scales made of rationals

And update examples, but keep the old X/Yo syntax for backward compatibility.

IDK how much work it would be to add custom oscillator construction, but it would be something good for users who want to experiment with the ideas of Tuning, Timbre, Spectrum, Scale. I think this would be a pretty valuable feature because some tunings dont sound good with normal harmonic oscillators, such as 10TET. I would imagine the syntax would be an array of frequency and amplitude ratios, and the program would sum this set of sine waves into one OSC. Also it would be nice to be able to stretch and shrink the partials of the current OSCs.

People might like some real instruments like piano, harpsichord etc. If open source sound files exist, Tone js has the ability to play them

Now all the code is activated sequentially in order.
But sometimes it is of use to sound only one specific line of code at a time.
It gives freedom to decide what to play not using pesky commenting / uncommenting.
It can be implemented as a separate button activating the line on the cursor or a short-cut (like in Supercollider).

Links to xenp.io

Makes for some much more readable tunes

0,1,2,3,4 optionally becomes 0 1 2 3 4

{1/1,6/5,5/4,4/3,3/2} optionally becomes {1/1 6/5 5/4 4/3 3/2}

Allows #25 to happen

Complements (bpm:...). Considering (bms:...) for "beat milliseconds", so the first letter alphabetically groups it alongside bpm, and milliseconds used rather than seconds because

• time spans will tend to be short
• seconds aren't hard to represent as milliseconds
• it avoids a limit of decimal point that may give a false sense of accuracy, and
• I'd like to avoid having alternate ways of writing the same node to reduce the width of the lexicon and amount of docs

So instead of {0,3,5,7,10} you could go {m3 2 2 3 2} or something. Means that modes can be copy pasted straight from the wiki

Must have been a regression in the hash format change.

You can almost do this in the console already, throwing a codemirror input that allows arbitrary js to be executed and a set of functions to send chars to the textarea would be quite interesting and a potential escape hatch for people wanting the grammar to become more dynamic.

Especially when the keypad pops up. Remove it from small screens, and show it only in the info panel in those cases.

As a beginner getting started, whatever you can do to make parse errors more specific would be a big help as people getting started (i.e. me) don't really understand when they're misusing the language.

Example:

(env:0158)0"-.....

Error: Unexpected token at 1:13.

The problem is that " goes before the note not after, but it took a while to figure out.

A possible different fix might be highlighting on specifically what the error is about; right now I think the line color changes a little bit but it isn't visually obvious what the problem is

Have a look at this intentional error (emoji). The second line (not the problem) is red, drawing my eye.

Leave space for possible future inclusion of ups and downs notation

Perhaps like [= insert math equation here]. Allow arbitrary js math, provide some named variables too perhaps (possibly r for root, l for last pitch played). Could work as an escape hatch.

Now the links are easily get big if the sequence is sufficiently large.
It is understood that links contain all the information about the sequence.
It is maybe so that there isn't sufficient storage to store all the instances.
Maybe apply reversible compression if length of sequence exceeds some range?

I've been using this to write down small notes to myself for random tunes I think of. Really needs a percussion voice couple with #8 to work better for that.

I'd like a JI ruler that shows the current scale and notes being played vertically against selected JI intervals or perhaps custom edos or custom scales (maybe collects all the scales from the current file and allows them to be toggled on or off)

Perhaps / and \ as used by guitar tabs? Or does that conflict too much with the slashes used in ratios? How would the speed of the slur be indicated? Can arbitrary shapes of slur be somehow notated?

Very likely caused by dendriforms sets being asynchronous enough that react can sometimes schedule a top-down update between the set being called and the sets bottom up update, so that the top down update doesn't match exactly what the textareas local state is at the time its applied, which forces the new text content to be set fresh, and the cursor position to be bumped to the end. Just guessing. Really dendriform should be made to be synchronous by default and optionally async, so react can do a normal old sync update after keypress has been captured, without relying on storing local state in useInput.

But if thats true then the same issue may be able to occur more sparsely if debouncing is being used, as that can only be async. It may be a greater issue with coordinating bottom-up and top-down state updates. But in those cases I don;t mind forcing dendriform users to use useInput, as it's intended to be used on inputs, and most things (e.g. not form inputs) dont care about whether the change was sync or not and just adjust to cope with the new props.

Also likely the issue holding up #20