Branching away from puredata?

Using javascript and the web browser dynamic html to make controls for the fractal sequencer.

As well as a xenharmonic sequencer, a Moments of Symmetry(Erv Wilson) matrix generator

to go along with Erv's mosedo.pdf There are 2 versions of it , one without the FUDI to pd stuff
https://ia601408.us.archive.org/1/items/mosedo.html/mosedo.html?p=17&g=7 , the other with and another expected soon

that works with  any generator. The edo MOS are finite and are the "Well Formed" set of MOS,

Finally Andrew Milne figured out how to calculate the cardinalities without using continued fractions  or brute force.

So now it is quick to generate the non rational MOS alongside the closest approximating "Well Formed" MOS using very

simple code which took forever to even comprehend on paper with pencil.  Things like this are complex for me with pd

Now that the algorithm is coded up in javascript a pd version would be simpler to make however , having this part of

the puzzle in the browser will make it easier for a general audience to use.

The new text object makes things like a database of modes easy to access in pd and also is easy enough

to implement a user interface with the entire list on a webpage.  In pd a simple abstraction that increments

an index for sets with {p} tones    , an index for the modes of  sizes {s} , then the index into the modes {m} with
s number of notes within  scales having p tones. Example:

from

14 tone equal modes:

2 3 2 2 3 2                    Quasi-equal Hexatonic
2 1 2 1 2 1 2 2 1      Gould Nonatonic
1 2 1 2 1 1 2 1 2 1  Decimal-10
2 3 3 3 3                        Godzilla-5
2 2 1 2 1 2 1 2 1      Godzilla-9
3 2 2 3 2 2                    Hedgehog-6
1 2 2 2 1 2 2 2           Hedgehog-8
3 3 2 3 3                         Semaphore-5
1 2 3 2 1 2 3                Superpelog-Pelog
1 2 1 2 1 2 1 2 2        Superpelog-9

p=14,

s=6,
m=0: 2 3 2 2 3 2                    Quasi-equal Hexatonic
m=1: 3 2 2 3 2 2                    Hedgehog-6

For this set it is not too much to cycle through the entire list

but for  12 and 31 edo there are many more modes.

Would probably be ok to only divide the entire list up in files with

the all the modes in scales with p tones instead of splitting up the list further.

The list was easy to add user interactive <div> tags and mouseover functions

that send the selected mode to the synthesizer in javascript and html.

With the text object the user interface is a little different.

It's only a float atom index  into the list,  a canvas display for the currently selected

item in the list. , and a bang to send the mode off to where it can be used  vs the entire
interactive scrollable list in the browser.  Some of the modes are specific to other scales

that are Just Intonation as well as cents  rather than equal division scales.
So from within pd there are abstractions that accept over FUDI a scale in cents as well
as a scale in Just intonation.  simply snagging the intervals from the html and inserting them

into the section heading onmouseover function input is all that is needed for FUDICalization

implementation.  With the textobject the scale intervals are easily snaggable with [text get].

For the equal division  scales an abstraction exists that only needs a message containing
an equivalence interval or "xTave" and number of divisions. for Bohlen Pierce - xTave = 3

3 and divisions = 13.  The text object could contain the entire message on one line

EqualDivision 13 3;

and the text that describes it "Bohlen Pierce Equal Divisions" on another line.

This is getting simpler now, I think it's a good format for data of this type which

can describe in different ways , information for the user and the machine.

for the modes  , since they are all modes and described in the same way

the "mode part of the message neednt be in the text object.

Since all the data has a descriptor and information

the index could simply be the entire list  in 2 line pairs.

description;

data;

description;

data;

< >

next / previous item is easy

for(x=0, x<2,x++)
|

[t f  f]

{float to spigot selects , then float to text get}

[text get]

 {out to spigot inlets}                        [select 0]

                                              [spigot]

                                              [canvasrx label description(

[canvas[o][<][>]]redtangled

                                    [select 1]

                      [ spigot ]

[r bang(      /  

 |               /        
  |           /

   [list]

What about dynamic visualization of data that is variable in size as well as

variable element controls like a piano roll midi sequencer?

it's being implemented in tcl.

how do you do it without tcl and without data structures?

Food for thought!

Is pure data's entire reason for existence to perplexingly confuse  the

virtual parallel patchcordianist?

The webpage interface: xensynth/burningship/pdApplet/xensynthcontrol.html
https://archive.org/details/Xensynth10.01

What in the Godel Bear does this mean?

"Loading the file versus loading the object

There are multiple forms for storing objects on the filesystem, including abstractions, single- and multi-object library files, etc. Then there is the representation of what objects are assigned to which symbols. These don't need to be the same thing. Each patch has its own table of which symbols are attached to which objects, and this can be separate from which objects are actually loaded into memory.

One idea for handling this is to have separate tables of symbols for which object files are loaded, versus which symbols are tied to which objects for a given patch. It seems for this to be workable, there would need to be a "loaded" table, then each patch would generate its table from the loaded table. Then if an object isn't in the loaded table, the loaded table handler would go and try to load it."

https://puredata.info/dev/PdNamespaces