[PD] [PD-announce] Ofelia v3.0.1 released.
Hi, Ofelia v3.0.1 is now available on Deken. Changes: - Added more examples (3d, drawing, math..) - Fixed type checking issue in "ofxOfeliaPdBindings.i" - Fixed bug when outputting a table with a string key using ofOutlet() - ofArray's array elements can be accessed using square brackets Thanks! Zack ___ Pd-announce mailing list pd-annou...@lists.iem.at https://lists.puredata.info/listinfo/pd-announce ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Problem loading Ofelia
On 27/8/19 4:44 μ.μ., Max wrote: > On 24.08.19 12:53, IOhannes m zmölnig wrote: >> On 8/24/19 11:46 AM, Alexandros wrote: > >> afaict, you have three options: >> - run ofelia on a compatible linux installation (i don't know which one >> that would be) >> - compile ofelia yourself on your system >> - nag zack until he releases a version that is compatible with your >> system > > Compiling it yourself is fairly straight forward and reasonably well > documented. I already did it and reported back here. See here https://www.mail-archive.com/pd-list@lists.iem.at/msg18577.html ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Problem loading Ofelia
On 24.08.19 12:53, IOhannes m zmölnig wrote: On 8/24/19 11:46 AM, Alexandros wrote: afaict, you have three options: - run ofelia on a compatible linux installation (i don't know which one that would be) - compile ofelia yourself on your system - nag zack until he releases a version that is compatible with your system Compiling it yourself is fairly straight forward and reasonably well documented. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] 0.50-0 released
Hi Miller On Mon, 2019-08-19 at 20:33 -0700, Miller Puckette wrote: > To Pd-announce: > > Pd version 0.50-0 is available [...] [pdcontrol] is a godsend! I can't count the cases where this could be useful. [slop~] gives tremendous amounts of new possibilities, too.. (think dynamic processors and envelop generators, etc.) Cool! Thank you! Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] preferences - startup parameters unreachable
Hi,
open "regedit" (press the windows key and type "regedit") and navigate
to : HKEY_CURRENT_USER\Software\Pure-Data
locate the "flags" entry and right-click on it and hit "modify".
wipe the [ -verbose "all" ] in the "value data" box.
:)
Mensaje telepatico asistido por maquinas.
On 8/27/2019 6:09 AM, ro...@dds.nl wrote:
> hi,
>
> after having added through the menu in start-up flags: -verbose "all"
> trying to open the start-up menu is impossible.
> in the console it gives this message:
>
> (Tcl) UNHANDLED ERROR: extra characters after close-quote
> while executing
> "pdtk_startup_dialog .gfxstub25f3c28 0 "-verbose "all""
> "
> ("uplevel" body line 3)
> invoked from within
> "uplevel #0 $docmds"(Tcl) UNHANDLED ERROR: extra characters after
> close-quote
> while executing
> "pdtk_startup_dialog .gfxstub25f39c8 0 "-verbose "all""
> "
> ("uplevel" body line 4)
> invoked from within
> "uplevel #0 $docmds"
>
> rolf (on windows 10)
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Re: [PD] preferences - startup parameters unreachable
On 27.08.19 11:09, ro...@dds.nl wrote: > > after having added through the menu in start-up flags: -verbose "all" what is that supposed to mean? > trying to open the start-up menu is impossible. https://github.com/pure-data/pure-data/issues/579 i'm afraid your only chance is to fix the prefs outside of Pd (e.g. regedit) or delete the preferences altogether and start anew. hmsdg IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] preferences - startup parameters unreachable
hi,
after having added through the menu in start-up flags: -verbose "all"
trying to open the start-up menu is impossible.
in the console it gives this message:
(Tcl) UNHANDLED ERROR: extra characters after close-quote
while executing
"pdtk_startup_dialog .gfxstub25f3c28 0 "-verbose "all""
"
("uplevel" body line 3)
invoked from within
"uplevel #0 $docmds"(Tcl) UNHANDLED ERROR: extra characters after
close-quote
while executing
"pdtk_startup_dialog .gfxstub25f39c8 0 "-verbose "all""
"
("uplevel" body line 4)
invoked from within
"uplevel #0 $docmds"
rolf (on windows 10)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Why don't we implement zooming in Tcl?
Whether considering major or minor surgery; it helps that Pd is a GUI toolkit in its own right, albeit domain specific. Pd could rely more on its own widgets and internal message system to display dialog windows, thus reducing the nessecary amount of GUI-specific code. It is hard to explain in a few words but this experiment illustrates the approach, a generic mouse widget using an abstraction as its properties dialog: https://github.com/katjav/pd-mouse-trial A bonus of reusing Pd's powerful widgets: numbox (and here also the 2 dimensional mouse widget itself) can resize an object. No handles needed, imagine the lines of code being avoided this way. Katja On 8/27/19, Christof Ressi wrote: > Ideally we could manage to have the generic GUI interface as a compile time > option, so that the current Pd vanilla code could remain unchanged for > people who want to continue using the Tcl/Tk GUI. This would also mean that > the GUI interface could be as radical as possible, because it wouldn't > affect existing code/patches. > > In my dream world, Pd wouldn't know anything about its GUI editor. It would > just say: create the GUI part of "thing" for me and get notifications if > "thing" was moved, destroyed or clicked on. So no raw mouse events and > hitbox testing on the core (modern GUI frameworks like Qt already do this > automatically, and in a very optimized way). > > Christof > >> Gesendet: Dienstag, 27. August 2019 um 04:52 Uhr >> Von: "Christof Ressi" >> An: "Miller Puckette" , Pd-List >> Betreff: Re: [PD] [PD-dev] Why don't we implement zooming in Tcl? >> >> Hi, >> >> > Write or find a Tcl parser and bind all the tcl comands coming from Pd >> > to >> > new functions written for whatever toolkit you like. >> >> This is what I would like to avoid my all means :-) The Tcl commands are, >> well, just too Tcl specific. >> >> > Make an abstraction layer between Pd and the TCL calls, and swap in >> > compatible >> > calls to another toolkit. This has been proposed a few times but seems >> > like >> > major surgery. >> >> I think this is the way to go! It would certainly require major surgery >> but I think it would pay off tremendously in the future, because people >> could easily do alternative GUIs without forking the core. But first >> someone has to come up with a proof of concept. >> >> Christof >> >> >> > Gesendet: Dienstag, 27. August 2019 um 03:43 Uhr >> > Von: "Miller Puckette" >> > An: "Christof Ressi" >> > Cc: pd-dev >> > Betreff: Re: [PD-dev] Why don't we implement zooming in Tcl? >> > >> > Well, possiblities: >> > >> > Rip the GUI out and replace it (this is done in Purr Data) >> > >> > Write or find a Tcl parser and bind all the tcl comands coming from Pd >> > to >> > new functions written for whatever toolkit you like. This was done once >> > by a very smart person and shown (I think) at the first Pure Data >> > Convention >> > (Graz!) Perhas Iohannes will remember who this was or know how to find >> > it. >> > Maybe it's even in the Pd convention book... >> > >> > Make an abstraction layer between Pd and the TCL calls, and swap in >> > compatible >> > calls to another toolkit. This has been proposed a few times but seems >> > like >> > major surgery. >> > >> > (previous suggestoin, lite version) - Hang onto Tcl/Tkfor dialogs and >> > the >> > like, but redo the "pd window" calls using some other toolkit (less >> > major >> > surgery, but then you're using two toolkits, ugh.) >> > >> > Do somtheing not int he above list (and that I haven't though of :) >> > >> > M >> > >> > >> > On Tue, Aug 27, 2019 at 02:38:17AM +0200, Christof Ressi wrote: >> > > > Maybe I'm missing something obvious? >> > > >> > > Of course I did... We send raw Tcl commands from the core with the >> > > actual canvas coordinates and this complicates things because of how >> > > Tk's "scale" method works... >> > > >> > > Maybe it's time to eventually refactor the GUI messaging and use >> > > abstract commands instead of actual Tcl code, with logical coordinates >> > > instead of actual coordinates... This would mean that zooming could be >> > > implemented easily on the GUI side. >> > > >> > > But what's more important: people can replace the Tk GUI with other >> > > (better) GUIs. I think the libpd people would love that as well, >> > > because apps could easily integrate Pd's GUI into their GUI framework >> > > of choice. Also, people can offer alternative GUIs for Pd vanilla. >> > > Personally, I can imagine writing a Qt GUI. This would be similar to >> > > how Supercollider has alternative language clients which all talk to >> > > the Server via well-defined OSC messages. >> > > >> > > >> > > >> > > I appreciate Pd's minimalism but a simple GUI should also be a *fast* >> > > GUI. The Tk canvas implementation is actually pretty terrible >> > > performance-wise. Moving an object in a larger patch maxes out a whole >> > > core(!) on my Laptop. It appears that Tk simply redraws the whole >> > > canvas :-( Any decen
