Hi Billy,
Have to admit much of that went over my limited skillset. However, the MOD stuff is composition magic.
Thanks for sharing,
Julian
On 2 March 2016 at 13:55, Billy Stiltner billy.stiltner@gmail.com wrote:
My struggles with it are not really limitations of pd. It's the way I have went about modelling a polyphonic synthesizer and using the tcl controls as MVC then making the controls a part of the preset machine. Everything is available for me to break the view away from the DSP its just that there are some pretty nifty things going on with the view. For instance there are toggles that change the range of the envelope ADR controls so you can have 1s,3s, 10s, and 30s controls. This is dynamic controls. Another is a dial or knob that is quantized and the range changes depending on the number of intervals the scale has per equivalence interval or what I like to call the xTave , it is used to offset the frequency in a quantitative way in steps of the scale. It doesn't matter if the intervals are specified in cents ,JI,or an edo. The scales all end up in an frequency ratio list. So the knob is used to like the "tune" or "pitch" knob yet instead of continuous or cents adjustment it allows an offset based on the scale. There are 2 banks of oscillators and only one uses this kind of control, the other is just a regular dial that offsets by a floating point. At this point of development it was found that there were way too many controls and being attached to the presets as well as the synthesizer's realtime adjustments. So Instead of making more controls I tried to reduce the amount of controls by changing the send and receive names dynamically. I guess it works for controls that are not dynamic but gets really complicated for the controls that have their properties change at runtime. Here is a thread about it. http://forum.pdpatchrepo.info/topic/5724/dollar-signs-in-objects-and-message... Also some discussion in this list. That can be solved once the controls are broke free from the presets and DSP. Making everything FUDI friendly with super neat message boxes and routing of messages through the first inlet like that can be seen in Miller's multi pickup guitar effects monster and patch repository or MAX/MSP XFM~ will be quite the task. Those are great examples of how patching should be. 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 http://www.huygens-fokker.org/docs/modename.html 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list