[L2Ork-dev] Purr Data: Availability of Else and Cyclone libraries?

Alexandre Torres Porres porres at gmail.com
Fri Feb 3 16:20:05 EST 2023


Em sex., 3 de fev. de 2023 às 17:40, Ico Bukvic <ico at vt.edu> escreveu:

> Patches could be easily edited using sed and awk.
>

I'm mostly using for a header. There could be a header abstraction instead
and it could be rather easy to using magic programming skills to replace
and edit this.

I could do manually as I'm usually not in my right mind :) I've done worse
things... I'd do it as a last resource if it all came down to this. I might
even do it because of plugdata, which ported it just for the documentation
but it's not officially supporting it... let's see


>
> Hopefully you saved yourself the trouble and merged hammereditor changes
> from pd-l2ork trunk, as that one already works there.
>
> Best,
>
> Ico
>
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Institute for Creativity, Arts, and Technology
>
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
>
> ci.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Fri, Feb 3, 2023, 15:20 Albert Graef <aggraef at gmail.com> wrote:
>
>> Ok, so [comment] is another one for the TODO list, because no one in
>> their right mind would volunteer to manually edit 200+ help patches.
>>
>> On Fri, Feb 3, 2023 at 8:03 PM Alexandre Torres Porres <porres at gmail.com>
>> wrote:
>>
>>> by the way, the [comment] object, which hasn't been ported, could still
>>> be left of with no real damage, since it always missed in l2ork/purr data.
>>> The thing is that I use it a lot in the documentation of Cyclone. I
>>> wouldn't mind removing it though from all help files (but [comment] itself
>>> of course). I just don't have the patience to do it.
>>>
>>> I would gladly accept a PR that removes all [comment] objects from all
>>> help files and these could be replaced by regular labels in [cnv] objects.
>>> If anyone want to do that for us, should be simple and easy to do, it just
>>> requires manual labor and doing a repetitive task for over 200 help files
>>> :)
>>>
>>> If that is done, I don't think that merging the new Cyclone will be that
>>> complicated. It will probably still miss other features that haven't been
>>> ported yet and that's fine too as they were already missing. The biggest
>>> issue seems to rely on porting [comment] from scratch just because help
>>> files would be kinda ruined.
>>>
>>> cheers
>>>
>>> Em sex., 3 de fev. de 2023 às 15:21, Alexandre Torres Porres <
>>> porres at gmail.com> escreveu:
>>>
>>>> Em sex., 3 de fev. de 2023 às 14:56, Albert Graef <aggraef at gmail.com>
>>>> escreveu:
>>>>
>>>>> Also, as Alexandre mentioned, it makes sense for his cyclone and ELSE
>>>>> to stabilize a bit before we attempt to port them over.
>>>>>
>>>>
>>>> Cyclone should be stable, specially now with the last release I plan to
>>>> do this month
>>>>
>>>>
>>>>
>>>>> Then there's the issue of backward compatibility with legacy cyclone
>>>>> applications that needs some thought. Right now, people can still run many
>>>>> of their old patches that they used to run with classic pd-l2ork or
>>>>> pd-extended with Purr Data, and we'd like to keep it that way. I'm not sure
>>>>> how compatible the latest cyclone still is with older versions. Alexandre,
>>>>> you should know, maybe you can shed some light on this?
>>>>>
>>>>
>>>> Cyclone is supposed to be backwards compatible, but there are minor
>>>> exceptions and issues specific to pd-l2ork/purr data, like the [coll]
>>>> object, which has a 2nd argument in pd-l2ork/purr data for the threaded
>>>> mode. The thing is that way back, still in MAX 4.0, a 2nd argument was
>>>> added to [coll] (and this was after Cyclone was developed). We included
>>>> this behaviour for proper and exact compatibility to MAX. So we created an
>>>> extra "@threaded" mode for [coll] and this was back in Cyclone 0.3 and this
>>>> matter was discussed at the time and mentioned to Ivica, I remember. This
>>>> seems to be the most complicated matter.
>>>>
>>>>
>>>>
>>>>> Maybe some of the tasks involved could be tackled in a future GSoC
>>>>>
>>>>
>>>> That would be great and I could get involved in that as some "mentor",
>>>> and also learn better from it how to adapt the GUI externals to nw.js and
>>>> also how to properly code GUIs in tcl/tk.
>>>>
>>>> cheers
>>>>
>>>>
>>>>
>>>>> but I wouldn't hold my breath for it. I'm tempted to look into it at
>>>>> some point, though. I've also been tossing around the idea to add another
>>>>> plugdata-like type of "light" build which would include cyclone and ELSE to
>>>>> mirror what's available in plugdata. That would be useful for those who
>>>>> might prefer Purr for development, but would also like to be able to run
>>>>> their patches as plugins via plugdata. I consider myself in that camp.
>>>>>
>>>>> Lots of tasks for the infinite TODO list (TM). ;-)
>>>>>
>>>>> Albert
>>>>>
>>>>>
>>>>> On Fri, Feb 3, 2023 at 3:05 PM Linux ROUEN Normandie <
>>>>> linux.rouen at free.fr> wrote:
>>>>>
>>>>>> Hello Jonathan and Albert,
>>>>>>
>>>>>> Is there any chance to have sooner or later available under Purr Data
>>>>>> (today with Pd-0.48.0 engine) the following 2 libraries ?
>>>>>> - Else <https://github.com/porres/pd-else> >= v.1.0 (this version
>>>>>> needs Pd Vanilla >= v.0.53-1)
>>>>>> - Cyclone <https://github.com/porres/pd-cyclone> (~ Max 7.3.5) >=
>>>>>> v.0.6.1 (this version needs Pd Vanilla >= v.0.52-1)
>>>>>> Today Cyclone (~ Max 4) in Purr Data is in a prehistorical version ~
>>>>>> 0.1 for years.
>>>>>>
>>>>>> Or at least the following 3 objects ?
>>>>>> - [else/keyboard] - this is a must to have for MIDI applications
>>>>>> - [else/sfont~] - a nice alternative to [fluid~]
>>>>>> - [else/midi] - an alternative to [cyclone/seq]
>>>>>>
>>>>>> Thank you.
>>>>>> - - - - - - - - - - - - -
>>>>>> Best,
>>>>>> Joseph Gastelais
>>>>>> - - - - - - - - - - - - -
>>>>>> _______________________________________________
>>>>>> 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, web: https://agraef.github.io/
>>>>> _______________________________________________
>>>>> 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, web: https://agraef.github.io/
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20230203/ec3018b2/attachment-0001.htm>


More information about the L2Ork-dev mailing list