Re: [PD-dev] tcl error message
Eric only replied to me, I'm sending my answer to him and the list Em ter., 30 de jun. de 2020 às 20:35, Eric Lennartson < lennartsone...@gmail.com> escreveu: > This abstraction is inside a subpatch that's in abstraction. > can you send me a folder with all the patches where the error presents itself? I couldn't trigger it by only loading your patch or if I put it in a subpatch and stuff. Em ter., 30 de jun. de 2020 às 20:39, Eric Lennartson < lennartsone...@gmail.com> escreveu: > Yeah okay, so you're completely right. The loadbang needs to change so > that it bangs after the parent patch is created. > yeah, I thought so :) but please don't change it, what you're doing is correct. The error needs to be fixed, and now I'm pretty positive my fix from https://github.com/pure-data/pure-data/pull/1079/commits/8ba3bd3b115d62dc8de6f93923fb3d64223fecc1 can also take care of this annoyance. But send me the whole thing so I can test it please ;) cheers > ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl error message
Em ter., 30 de jun. de 2020 às 19:05, Christof Ressi escreveu: > The error message comes from a IEM GUI element. > hmm, I thought it could be an external cause I made a search for ".x%lx.c delete %lx*IN0*" and couldn't find it, but it's there as ".x%lx.c delete %lxIN*%d*" (oops!). Anyway, for what I see, the error could be triggered by any of the iemguis then. I also suspect the fix for this would be related to something I've already been doing in a PR ( see https://github.com/pure-data/pure-data/pull/1079/commits/8ba3bd3b115d62dc8de6f93923fb3d64223fecc1 ). The reason is that I was dealing with a similar issue (exact same error, actually) in scope~ and fixed it with something like that. So if you want you can send me the patch Eric, and I can try and debug it and see if my fix deals with this issue or if I have to expand it. This could be triggered by the abstraction setting a receive name for the iemgui, so it tries to delete the inlets but it doesn't find it cause it is not visible and hasn't been drawn/created. See if you're doing that. cheers ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl error message
Em ter., 30 de jun. de 2020 às 19:29, Alexandre Torres Porres < por...@gmail.com> escreveu: > > > Em ter., 30 de jun. de 2020 às 18:58, Eric Lennartson < > lennartsone...@gmail.com> escreveu: > >> Not sure what else might be helpful to know. >> > > this error is triggered by a particular object, an external I strongly > believe. It might be helpful to know which one ;) > and just so it's clear, it'd be a bug in that particular external ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl error message
Em ter., 30 de jun. de 2020 às 18:58, Eric Lennartson < lennartsone...@gmail.com> escreveu: > Not sure what else might be helpful to know. > this error is triggered by a particular object, an external I strongly believe. It might be helpful to know which one ;) ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl error message
On 2020-06-30 23:57, Eric Lennartson wrote: > Got this error while making an abstraction. Only happens when I load the > patch as an abstraction, not when I open the file itself. Pd seems to > continue functioning normally, but I figured that y'all might want to know > about it. Not sure what else might be helpful to know. looks like the well-known problem with changing the appearance of iemgui-objects in a closed subpatch/abstraction. e.g. [inlet] | [number $1( | [hradio] gfmdsar IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl error message
The error message comes from a IEM GUI element. Please try to reduce the
abstraction to the minimum (while still triggering the error reliably)
and share it with us!
Christof
On 30.06.2020 23:57, Eric Lennartson wrote:
Got this error while making an abstraction. Only happens when I load
the patch as an abstraction, not when I open the file itself. Pd seems
to continue functioning normally, but I figured that y'all might want
to know about it. Not sure what else might be helpful to know.
(Tcl) INVALID COMMAND NAME: invalid command name ".x10046c6f0.c"
while executing
".x10046c6f0.c delete 105031800IN0"
("uplevel" body line 267)
invoked from within
"uplevel #0 $docmds"
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
[PD-dev] tcl error message
Got this error while making an abstraction. Only happens when I load the
patch as an abstraction, not when I open the file itself. Pd seems to
continue functioning normally, but I figured that y'all might want to know
about it. Not sure what else might be helpful to know.
(Tcl) INVALID COMMAND NAME: invalid command name ".x10046c6f0.c"
while executing
".x10046c6f0.c delete 105031800IN0"
("uplevel" body line 267)
invoked from within
"uplevel #0 $docmds"
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd talking to host in blocksize 1
Two ways: 1. make a 64-element FIFO for either the input or the output; this will introduce a small delay in the signal path; or (2) recompile Pd for a lower blocksize. This will increase CPU load but should allow avoiding any signal path delay. cheers Miller On Tue, Jun 30, 2020 at 10:01:08PM +0200, Max wrote: > Hi list, > > when using libpd as a plugin to a host, say VCV Rack or a DAW, it is > desirable to not only be able to process small blocksizes internally, but > also talk to the host in a smaller blocksize than the default 64. > Especially in the case of VCV Rack this is almost a necessity to do > meaningful analog modelling, recursive feedbacks, etc. > > Would this feature be possible to implement at all given the limitation of > Pd itself? > > M. > > > > ___ > Pd-dev mailing list > Pd-dev@lists.iem.at > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!WQZ2fAL5CPErgF-KeaTdV0CDbnx7Nt8zGD7KykEbJRVIwpfX3B-wGsFubkoP$ ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] libpd talking to host in blocksize 1
Hi list, when using libpd as a plugin to a host, say VCV Rack or a DAW, it is desirable to not only be able to process small blocksizes internally, but also talk to the host in a smaller blocksize than the default 64. Especially in the case of VCV Rack this is almost a necessity to do meaningful analog modelling, recursive feedbacks, etc. Would this feature be possible to implement at all given the limitation of Pd itself? M. ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
