[L2Ork-dev] Fwd: Re: Suggestions for PurrD GSoC 2018

Tue Mar 13 01:06:01 EDT 2018

Hi,

one of my main problems I'm always fighting with is the slow gui of pd
and Purr Data. If one likes to show changes of a large amount of
settings in real time, the real time engine gets slow and I have to set
the delay of pd/Purr Data quite high - which is not so handy, when you
work with real time effects on microphone input.

As an example I send a screenshot of one of my patches with this mail.
Changing the sequenzers or the controller settings demand too much time.
I've changed the sequenzers already from structs and drawarrays to usual canvases.
Using canvases is much faster than structs and any [drawpolygon]

I wonder if there's an solution to this, as usual browser engines should
be fast enough on this tasks.

One of my observations on Purr is, that objects get redrawn more than
one time. For example using ctrl-y  on a large patch seemes to run
through all objects a couple of times, instead of running through the
selected objects once.

I also already made a feature request on the issues list of Purr Data
for getting a connection to html5/js. It would be much easier to style
controls via html and js and work with send/receives as all this effort
one has to spend for styling inside of pd/Purr. The quite new ability of
Purr to be able to use svgs is a good step towards a more flexible
design, but I doubt that it will be a fast technique.

Regards,
Xaver

Am 12.03.2018 um 20:14 schrieb Giulio Moro:
>>> With Gen, Max offers a possibility to develop DSP code in a dataflow
>>> environment. Is something like that possible in Pd?
>> This is something more low-level than expr~/fexpr~?
>> Not sure, because as I understood it, gen patches work on a block of size 1. So it's like writing C code. > The number of classes is much smaller, of course.
>> https://docs.cycling74.com/max7/vignettes/gen_overview
> as I understand it, the take home message from the gen~ environment is:
> - it allows to use data-flow to generate "gen~" code, which can then be exported as C++. I think this gets compiled live at runtime, so you always get efficient CPU performance.
> - inside gen~, you have a blocksize of one, which allows to do sample-by-sample computations.
>
> As a consequence, it allows:
> - executing sample-by-sample computations that perform much better (CPU-wise) than using [block~ 1]
> - even if you don't care about sample-by-sample computation, it should still be more efficient to write something in gen~ rather than connect together a bunch of objects. The performance advantage - as I understand it - should come from removing the overhead of function calls and allow for better compiler optimizations (as the code is all compiled together) (however I have noticed that on some platforms the compiler's optimizer fails to do a good work with the C++ code generated by gen~).
> - export to vanilla C++ (useful for embedded platforms and for generating externals)
>
>  From the above it emerges that gen~ as it is in Max, it is not only about implementing the classes, but also about generating efficient compile-able code from the patcher and compiling it in real-time. There is surely much more than this that I am leaving out, but this is my insights after dealing with it over a year ago.
>
> Best,
> Giulio
>
> ________________________________________
> From: L2Ork-dev <l2ork-dev-bounces at disis.music.vt.edu> on behalf of João Pais <jmmmpais at gmail.com>
> Sent: 12 March 2018 18:44
> To: l2ork-dev at disis.music.vt.edu
> Subject: Re: [L2Ork-dev] Suggestions for PurrD GSoC 2018
>
>
> Thanks for the suggestions, João.
>
>> Data structures:
>> Implement new high-level objects to deal with elements: the current objects
>> are too basic, and programming is slow and repetitive, or impossible without
>> a gui (e.g. deleting scalars). Would it be possible to integrate the code
>> with Pd Vanilla afterwards?
> I'm not sure what you mean by "high-level" here. Could you explain a little
> more?
>
> Since the objects are really basic, it's always necessary to start from scratch to handle any data structures. I can later give a more complete list of features (made one already years ago and sent it to Miller), but I meant something that avoids repetitive tasks. E.g. "next 3" to jump to jump 3 scalars, or "index 10" to go to the 10th element, ... things like that, that have to be programmed each time.
> But regarding data structures in general, it would make more sense if these could also go into Pd-Van (and with that libpd, etc.) - if not, then it's better to just do some abstractions.
>
>
>> Html5
>> If Pd is already html, would it be possible to have Purrd running
>> automatically in the background of a html5 page on a website? At a first
>> stage without gui, but afterwards with it?
> There's already a project idea for this: "API for HTML5 Web Apps"
>
>> Dynamic object list "page"
>> An updated object list doesn't exist in Pd. Since many (all?) objects in
>> PurrD have documentation patches, it should be possible to create a dynamic
>> object reference page with columns such as name, library, explanation,
>> author, ... An example is at
>> http://puredata.info/Members/jmmmp/0.INTRO-100105.xls/at_download/file
> Are you talking about a patch here?
>
> Could be a patch, but maybe easier would be a local html page which adapts to any elements added to the extra folder, or even to Purr-D's path (would also be easier to search). All that meta information in the libraries is just sitting and not being used.
> (again, would be good to be Pd-van compatible)
>
> Regarding searching, I'm not aware of the latest state, but a couple more details:
> - seach window says how many elements were found ("x of y"). Maybe this was in already.
> - (also from max) when a variable is used in send/receive, clicking on that object opens up the subpatch where the matching send/receive is. Fast to find, and avoids repeating variables. Also for send~/receive~ + throw~/catch~
>
>
>> In/Out audio mappings
>> Another interesting feature in Max is a general in/out audio matrix that can
>> be changed on demand. This would allow to use different main inlets/outlets
>> without having to edit the patch.
> Sounds interesting.
>
>> GenPd
>> With Gen, Max offers a possibility to develop DSP code in a dataflow
>> environment. Is something like that possible in Pd?
> This is something more low-level than expr~/fexpr~?
>
> Not sure, because as I understood it, gen patches work on a block of size 1. So it's like writing C code. The number of classes is much smaller, of course.
> https://docs.cycling74.com/max7/vignettes/gen_overview
>
>
>
>> The only programming language I can program is Pd, so I can only offer
>> something related to that: testing patches, preparing documentation,
>> preparing examples, ... Also depending on the available time, of course.
> That would be extremely helpful.
>
>> More ideas might come, but I wanted to leave something just from the top of
>> my head.
> Thanks!
>
> If I get to do something more in Purr-d I could get more ideas to ask (I'm trying to prepare some materials for the LAC, so it would be a chance for it). But I have some issues, that either purr-d doesn't work on my desktop (it just doesn't start), or some things I need don't work as good as in pd-ext (data structures). If the workshops I'm proposing work out, I can try to push them to purr-d
>
> Joao
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2018-03-12 22_31_32-Greenshot.png
Type: image/png
Size: 718730 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180313/cb3c68ff/attachment-0001.png>