[PD] How's Pd limited?

Julian Brooks jbeezez at gmail.com
Fri Mar 4 17:54:20 CET 2016


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 at 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-messages
> 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160304/c5985558/attachment.html>


More information about the Pd-list mailing list