[L2Ork-dev] Ad hoc parsers in Purr Data

[Albert Graef]

I'm not against fixing bugs we inherited from vanilla. In fact I did
fix some of those long-standing bugs myself. Some of that got
accepted, some (like the range mismatch of bending/bendout) got
rejected upstream, but we still have all those fixes in Pd-l2ork and
Purr Data.

This problem is different because it may affect patch compatibility.
(If I recall correctly, it's been a while that I looked into this.)
This needs to be considered carefully. I'm firmly opposed to any
change which makes us loose the ability to exchange patches between
Purr Data and vanilla. That would be a real showstopper.

Albert


On Fri, Mar 23, 2018 at 10:57 PM, Ivica Ico Bukvic <ico at vt.edu> wrote:
> This conversation brings up a larger question. Should pd-l2ork/purr-data be
> affected by the development rate of vanilla?
>
> The whole reason pd-l2ork came into being was because of the wish to provide
> a platform that is more nimble and dare I say experimental in its
> development (and in turn ideally responsive to the fixing experimental
> dead-ends). I would hate to lose this critical differentiating factor in the
> new version as that was by far the most compelling reason for its existence
> to the extent that it can over time significantly diverge from vanilla (at
> one point I asked Miller if he was ok with me renaming it to something else
> to minimize confusion among the community--I proposed the name Miller :-),
> while optionally offering the -legacy flag that would disable behavior that
> breaks vanilla compatibility. FWIW, in the numerous conversations I had with
> Miller, he expressed little interest in fixing plethora of problems iemgui
> objects had/have due to a very valid concern of breaking backwards
> compatibility, even if it was an obvious bug. Pd-l2ork/purr-data has already
> significant amount of work on this end of things and one could argue we are
> already significantly diverging from vanilla except that for the most part
> these elements are largely transparent to the user with few notable
> exceptions.
>
> With this in mind, if we agree with this being the project's key
> differentiating trait, I see little purpose in allowing # to be silently
> converted to $ since upon reopening the properties the name is shown
> incorrectly and does not any more reflect user's input. More so, its silent
> conversion is bound to also introduce problems newcomers will be unable to
> troubleshoot (e.g. #2 will implicitly change to the 2nd argument of the
> patch).
>
> This is a bug IMHO that needs to be fixed regardless when and if vanilla
> decides to do so.
>
> Best,
>
> Ico
>
>
>
> On 3/23/2018 3:33 PM, Jonathan Wilkes wrote:
>>>
>>> A recent discussion in the pd list clearly stated that this should be
>>> considered a bug in Vanilla, not a feature.
>>
>> In that case I'm happy to test then port whatever fix Vanilla comes up
>> with. I suppose I can
>> just reopen the issue and add a comment that Vanilla is already working on
>> this.
>>
>> Anyway, there's another ad hoc parser in pd_canvas.js that splits into
>> chunks of a size
>> suitable to be received by the Pd.
>>
>> There's also an ad hoc parser in dialog_search.html that is a
>> quick-and-dirty conversion
>> from FUDI to text.
>>
>> -Jonathan
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef