[L2Ork-dev] a couple of questions

Gilberto Agostinho gilbertohasnofb at googlemail.com
Wed Sep 17 20:53:22 UTC 2014


Thank you very much then, Ivica; so I will keep reporting bugs and ideas 
as I find them, I am happy to help with what I can do. I got really 
excited about pd-l2Ork and I am spending a great deal of time playing 
with it and testing it. You see, I recently switched from Windows to 
Linux, and then from Max MSP 6 to Pure Data. This transition from Max 
was not as easy as I expected, there were so many little things were 
bothering me with pd. Now pd-l2Ork solved the majority of my issues, and 
I am really happy about it.

As for the arrays, I tested saving and opening a file in pd-extended 
0.43.4 containing three arrays, one displayed as points, one as polygon 
and one as Bezier curve. After saving and opening it again, the display 
of the arrays remained the same, which means that the odd behaviour you 
describe is only present in vanilla pd.

As a final comment, if you want me to run any tests with pd-extended 
just let me know.

Best,
Gilberto

On 17/09/14 19:30, Ivica Bukvic wrote:
>
> No worries, Gilberto. Thank you very much for your bug reports, they 
> are very much appreciated. Regarding graph drawing I discovered that 
> vanilla draws the graph one way and once it is saved it is displayed 
> another was (point vs curve). So, in pd-l2ork we set out to explicitly 
> create and save graphs in a consistent fashion. I thought this also 
> meant it would maintain backwards compatibility but that apparently is 
> not the case. Regarding the Bezier curves, tkpath does not have that 
> feature for the time being it is disabled until we either properly 
> implement it in tkpath (which is less likely option) or finish our 
> migration to qt and implement it there (more likely but may take a 
> while). HTH
>
> On Sep 17, 2014 3:01 PM, "Gilberto Agostinho" 
> <gilbertohasnofb at googlemail.com 
> <mailto:gilbertohasnofb at googlemail.com>> wrote:
>
>     Hi Ivica, hi all,
>
>     I found one more compatibility problem between pd-l2Ork and
>     pd-extended. This time it is related to displaying arrays. In
>     pd-extended, there are three ways of graphing arrays: Points,
>     Polygon, Beziercurve. Here is what is happening:
>
>     - if an array is saved as "points" in pd-extended, it will open as
>     "polygon" in pd-l2Ork
>     - if an array is saved as "polygon" in pd-extended, it will open
>     as "points" in pd-l2Ork
>     - if an array is saved as "beziercurve" in pd-extended, it will
>     open as "polygon" in pd-l2Ork
>
>     Here is an image of a same file opened in both programs at the
>     same time:
>     http://s29.postimg.org/7cadlxxqf/Screenshot_from_2014_09_17_13_46_40.png
>
>     This issue particularly influences the object [spectrogram~] from
>     the jmmmp library, since it is displayed as "points" now in
>     pd-l2Ork (which is arguably worse), and the user cannot fix it by
>     himself unless he launches pd-l2Ork as root.
>
>     And just one last comment: I do hope that these e-mails about bugs
>     and/or suggestions that I have been sending to this list lately
>     are not "flooding" you all with small issues. If you feel that
>     these issues are not relevant at the present time or if there is a
>     better way of reporting bugs and small inconsistencies, please let
>     me know. My main intention when writing here is to collaborate in
>     order to improve pd-l2Ork.
>
>     Best,
>     Gilberto
>
>
>     On 15/09/14 22:34, Gilberto Agostinho wrote:
>>     Hi Ivica,
>>
>>     As for the other e-mail, here are my comments:
>>
>>     - I understand your approach of implementing things into the core
>>     of the code, but I believe that allowing users to write tcl
>>     plugins allow them to greatly customize their installation, as
>>     well as share interesting solutions. Nevertheless, here is a
>>     short demo of the completion-plugin and category-menu-plugin I
>>     mentioned before, which I believe could be very beneficial to
>>     pd-l2ork (you probably have to watch it in HD in order to be able
>>     to read, I recorded the whole desktop and not only pd's window):
>>     https://www.youtube.com/watch?v=CO8Zi_Ae_-I
>>
>>     - another interesting plugin is the full screen plugin, which
>>     allows full screen use by hitting F11 on the keyboard
>>
>>     - If I manually change the file .pdl2ork, then I am able to add
>>     folders to the path. I wonder why I can't do it via pd-l2Ork.
>>
>>     - Still about settings that are not saved: if I change the colour
>>     scheme and then I restart pd-l2Ork, it reverts back to the
>>     default colours. It also would be nice to allow users to save
>>     their presets, since you let them change the colours themselves
>>     and it would be frustrating to spend time preparing your own
>>     palette only to lose it next time.
>>
>>     - pity about initialization of JACK, but that's totally
>>     understandable. In the end, one needs only two extra clicks to
>>     start it manually.
>>
>>     - I already wrote about [gcanvas] on my previous e-mail, but just
>>     restating: part of ggee, default with pd-extended.
>>
>>     - As for [prepend] vs [list prepend], I think it could be nice to
>>     leave obsolete objects in order to maximize compatibility (I have
>>     seen many patches using [prepend]). On top of that, I believe
>>     that [prepend] works not only with lists, but also with any
>>     strings, and it is very useful to set a value to a message box (I
>>     requires one less object to do this job). Have a look:
>>     http://s12.postimg.org/f45zkztx9/foobar.png - or am I missing
>>     something here?
>>
>>     Thanks a lot for all the commenting of my questions, I really
>>     appreciate your time and the effort put on Pd-l2Ork. If there is
>>     anything I can do to help out, please let me know.
>>
>>     Best,
>>     Gilberto
>>
>>     On 15/09/14 18:54, Ivica Bukvic wrote:
>>>
>>>     Again, thank you for the update as well as for kind words re:
>>>     pd-l2ork, Gilberto. Please see my comments below.
>>>
>>>     On Sep 15, 2014 10:54 AM, "Gilberto Agostinho"
>>>     <gilbertohasnofb at googlemail.com
>>>     <mailto:gilbertohasnofb at googlemail.com>> wrote:
>>>     >
>>>     > Hello list,
>>>     >
>>>     > So after successfully installing pd-2lok side-by-side with
>>>     pd-extended, I am finally playing around with it. I am extremely
>>>     impressed by it, the new features are absolutely stunning! That
>>>     said, I do have a couple of questions/comments about it, and I
>>>     hope this is the right place to ask them (I tried the main Pure
>>>     Data forum, but I think not many users there are working with
>>>     pd-l2Ork).
>>>
>>>     Either place is fine, although perhaps this one is a bit more
>>>     appropriate.
>>>
>>>     >
>>>     > - Pd-l2Ork does not seem to recognize nor execute any of my
>>>     *-plugin.tcl files (pd-extended automatically does it for any
>>>     file ending with -plugin.tcl). Is this feature not yet
>>>     supported? If so, is there any plan to implement it? It would be
>>>     a huge pity to live without it, since there are great tcl
>>>     plugins available for pure data, such as auto-completition, full
>>>     screen by pressing F11 and one called category_menu-plugin.tcl
>>>     (this last one is my absolutely favourite).
>>>
>>>     We haven't implemented plugins as we prefer to implement things
>>>     into the core of pd-l2ork and also because we are looking to
>>>     migrate gui to qt soon which will obsolete a large number of
>>>     tk-specific workarounds. Pd-l2ork already supports more flexible
>>>     implementations of some of the plugins, like hide menu which in
>>>     pd-l2ork can be done per canvas rather than only globally for
>>>     the entire pd  instance. I am not familiar what plugins you
>>>     listed do beyond what you mentioned above, so if you think these
>>>     should be a part of pd-l2ork, we can certainly look into it.
>>>
>>>     >
>>>     > - I am not able to add a new folder to pd-l2Ork's path. To be
>>>     more exact: I do manage to add it, but then when I restart
>>>     Pd-l2Ork (so all externals would be reloaded) the folder is not
>>>     on its path and the abstractions there contained cannot be
>>>     loaded. How can one edit the path?
>>>
>>>     Did you try changing .pdl2ork file in your home folder? That is
>>>     what it uses for its user-specific settings file.
>>>
>>>     >
>>>     > - Is it possible for pd-l2Ork to automatically start JACK by
>>>     itself as pd-extended does? Now I have to manually open
>>>     QjackCtrl, start JACK and then start pd-l2Ork
>>>
>>>     As of right now, unfortunately no, mainly because so far it
>>>     seemed better to have full control over how many channels jack
>>>     should start and how they should connect to pd-l2ork, than deal
>>>     with default connections that only work in limited situations.
>>>     As always, we are open to alternative implementations, but as it
>>>     seems right now it is a choice of either using the incomplete
>>>     implementation or reimplementing everything tools like qjackctl
>>>     does which seems awfully redundant.
>>>
>>>     >
>>>     > - [gcanvas] : this very nice pd-extended GUI object is
>>>     missing, and I believe quite a lot of abstractions use it (I
>>>     found that even some of GEM tutorials included in pd-l2ork have it)
>>>
>>>     We build Gem from the latest git. I unfortunately have not
>>>     tested all its patches so if this is something we should have
>>>     (and it certainly seems so), we will gladly add it to the next
>>>     release. I could use more info about that object as I do not use
>>>     extended or vanilla. Namely, is it a core object or a
>>>     third-party external and if so to which lib does it belong to?
>>>
>>>     >
>>>     > - [prepend] : very useful pd-extended object (part of cyclone)
>>>     is also missing. Why wasn't this library included in this
>>>     release? I copied it from the pd-extended folder and it worked
>>>     perfectly well.
>>>
>>>     This is a part of continual work to prune redundant objects from
>>>     pd-l2ork.  [list prepend] is a perfect alternative and I have
>>>     built an abstraction using it to replace prepend (unfortunately
>>>     I have not included it with the release, which I probably
>>>     should--perhaps we could have a legacy folder with externals
>>>     considers obsolete?). This may prove a slight frustration in the
>>>     interim until we provide an online resource for legacy
>>>     externals, but in the long run I hope you will agree it will
>>>     result in a healthier ecosystem with no redundant objects and
>>>     therefore less confusion.
>>>
>>>     Hope this helps!
>>>
>>>     >
>>>     > Thanks a lot in advance.
>>>     >
>>>     > Best,
>>>     > Gilberto
>>>     > _______________________________________________
>>>     > L2Ork-dev mailing list
>>>     > L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>>>     > http://disis.music.vt.edu/listinfo/l2ork-dev
>>>
>>>
>>>
>>>     _______________________________________________
>>>     L2Ork-dev mailing list
>>>     L2Ork-dev at disis.music.vt.edu  <mailto:L2Ork-dev at disis.music.vt.edu>
>>>     http://disis.music.vt.edu/listinfo/l2ork-dev
>>
>
>
>     _______________________________________________
>     L2Ork-dev mailing list
>     L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>     http://disis.music.vt.edu/listinfo/l2ork-dev
>
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20140917/4d03a8f0/attachment-0001.html>


More information about the L2Ork-dev mailing list