[L2Ork-dev] a couple of questions

Wed Sep 17 17:30:36 UTC 2014

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> 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> 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
> > http://disis.music.vt.edu/listinfo/l2ork-dev
>
>
> _______________________________________________
> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttp://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/8ce9ab1e/attachment.html>