Hi Miller, maybe this is interesting for you:
https://github.com/pure-data/pure-data/issues/25
I got a fully working Pd (including ASIO support and externals) with only MinGW. The build process was quite straightforward.
Christof
---
** [feature-requests:#146] vst / lv2 plugin export**
**Status:** open
**Group:** Next Release (example)
**Created:** Sat Nov 18, 2017 12:31 AM UTC by steven shepard
**Last Updated:** Sat Nov 18, 2017 12:31 AM UTC
**Owner:** nobody
Could someone add the ablity toexport vst / lv2 plugins that a user makes? In pd effectly making pd a open source sythedit
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/feature-requests/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
---
** [bugs:#1306] subpatch object width moves to last created object in subpatch**
**Status:** open
**Group:** v0.47
**Created:** Thu Nov 16, 2017 12:19 PM UTC by Anonymous
**Last Updated:** Thu Nov 16, 2017 12:19 PM UTC
**Owner:** musil
**Attachments:**
- [subpatch_width_moves.pd](https://sourceforge.net/p/pure-data/bugs/1306/atta… (113 Bytes; text/plain)
Pd version 0.48-0
Win 7 / Intel Core i5
built-in sound
If you create a new mainpatch with a subpatch, containing one object like |t b|, then edit the width of subpatch |pd| to window width |pd | and then save the mainpatch and close it. After reopen it the width of subpatch |pd| ist minimal and the width moves to the object |t b |.
In text editor the ", f 23;" appendix moves from "X restore" line to the "X obj t b;" line.
I tried also Pd 0.46-7 under Win 7. same result.
Thomas Musil, Graz 2017.11.16
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
I've noticed in the TK 8.6 release notes <http://tcl.tk/software/tcltk/8.6.html>, there are a few new commands for moving existing canvas objects:
> Moving Things on a Canvas: New commands $canvas moveto, $canvas imove and $canvas rchars for moving and manipulating canvas items.
Perhaps this is something that can be used by the pd core instead of deleting then redrawing? I think there would need to be some sort of compile time or runtime check for the TK version though.
In any case, I'm still interested in ways to abstract the raw guilt tcl from the core usage in order to provide a generic interface for guis communication in libpd, so looking into this could be part of that...
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
That's the idea and I'd like to start with looking into porting Jonathan's work first. It would be nice to have a generic GUI layer so it would be easier to write GUIs and externals which would then work across flavors of Pd without relying directly on Tk drawing commands.
For instance, I'd like to be able to drop my custom CoreGraphics implementations of the Pd GUIs in PdParty and just receive draw commands I can build with CG instead and then send touch/click/key events into libpd. As it is now, I've basically reverse-engineered the GUI behaviors and communicate via send & receives.
Something to move toward.
> From: Fred Jan Kraan <fjkraan(a)xs4all.nl <mailto:fjkraan@xs4all.nl>>
>
> On 03-11-17 18:42, Dan Wilcox wrote:
>
>>
>> In any case, I'm still interested in ways to abstract the raw guilt tcl
>> from the core usage in order to provide a generic interface for guis
>> communication in libpd, so looking into this could be part of that...
>
> Is this the problem that Purr-data and CICM tried to solve?
>
> There were some ideas discussed atd Pd-CON-2016, and it would be nice to
> try to implement it as a proof of concept for 'standard' objects and
> maybe some IEM-GUI ones. Having something implemented makes it easier to
> talk about the problem (the 'code,talk' adagium).
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Hi,
I created a issue on the libPd repository (
https://github.com/libpd/libpd/issues/196) but perhaps it's more related to
Pd itself.
When I load a patch with [text define], it crashes (x_text.c line 280)
because x->x_scalar is NULL (because in scalar_new(), the function
template_findbyname(templatesym) returns NULL). So it seems that the
function can't find a template linked with the symbol "pd-text".
I can't figure out why it works in Pd but not in libPd. Perhaps, libPd
don't call a method to bind a template to this symbol at startup? Or
perhaps it's related to the fact that I use PDINSTANCE and PDTHREADS? I
can't figure out the solution so any idea is welcomed!
Cheers,
Pierre
---
** [bugs:#1305] Object created after canvas cannot be placed on it**
**Status:** open
**Group:** v0.47
**Created:** Wed Nov 01, 2017 02:50 PM UTC by Anonymous
**Last Updated:** Wed Nov 01, 2017 02:50 PM UTC
**Owner:** nobody
When i place an object, then a canvas, i cannot move the object onto the canvas, it dissapears behind.
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
I'm not really a huge fan of dynamics patching for this as simply open and close seems so much cleaner. That being said, I wish there was a vanilla way to close an open patch using it's $0, etc. That's more of a matter for my suggestions for a more general canvas info etc object...
The funny thing is that I never experienced this issue before, way back to the original system running in 2006. I think the difference is the hardware was slower, so the list might have been traversed before the patch was closed whereas now the patch closes more quickly while the message is mid-list. Or vice versa.
I haven't experienced this with Pd-extended either and have played many shows, including the one in Nov at the Pd-con. It's only with trying to adapt this setup to vanilla that I'm running into things. (Yes, I've still been using extended for some older sets but am transitioning now.)
Maybe this is something fixed in extended?
> On Sep 28, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> That said, I think that @Dan could use dynamic patching; I've just
> successfully tested creating/destroying abstractions every 5 millis, while
> the abstractions were forwarding a value updated every millisecond from
> master patch, without any crash.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>