[PD] slowly load a pd-patches/abs without dropouts
reduzierer at yahoo.de
Fri Jan 26 11:38:35 CET 2007
On Fri, 2007-01-26 at 09:40 +0100, Enrique Erne wrote:
> but when i dynamically create objects i never had dsp-chain problems so far.
i believe you as long as you don't create heavy abs. (though, if you
convert all abs to subpatches, that is not an issue anymore)
> On Sam Jan 20 15:25 , Roman Haefeli sent:
> >personally, i think it is not worth that much effort. unfortunately
> >creating a patch dynamically is NOT the same as 'executing' each line of
> >the pd-file.
> you are totally right, but i guess you didn't check the patch at all.
yes, you are right (sorry, if i said something, that i wouldn't have
said after reading your patch).
> basically it creates the patch line by line, but if a subpatch
> starts "#N canvas", it will search for its restore line "#X restore".
> there are important infos like subpatch position and the full name.
yeah, i know and in the beginning of netpd, i also messed around with
this. possibly i would find nicer solutions now to handle 'deepness' of
subpatches, particularly since [list] was introduced. but still, it is
much work to do and i wanted to drop the question, if it is worth that
much effort. of course, everyone has to decide him/herself if that is
> it checks the level of the subpatch so i don't have problems
> to create subpatches in subpatches.
yes, it is a solveable issue, nice that you solved it already.
> > this makes slow dynamic creation much more complicated than
> >necessary. also, in order to follow your rule to do EVERYTHIN slowly,
> >you would have to turn every instance of an abstraction into an subpatch
> >and therefore you would need to parse all dollararguments and convert
> >them to their appropriate values.
> actually my focus is mainly on abstractions. replace dollar-arguments
> (only in objects, not in msgs) is implemented in the attached patch.
> recursively turning every instance of an abstraction into a subpatch
> would be possible if we knew the abstraction names. that could be
> done with [pd abslist] but that's too netpd specific for the moment.
i see. or you could imitate the pd-behaviour: some search-pathes need to
be defined, and your parser could check for each object, if it finds the
code of it in one of the searchpathes. of course, that would introduce
the need of an external ([getdirlist], or what is its name?).
> > probably there are many problems more,
> >which don't come to mind right now.
> i have some:
> usually i ignore the first line of a patch "#N canvas".
> i think these values stands for window position and size
> and maybe fontsize.
unfortunately, i also don't know of a way to set window-position and
-size, when dynamically creating subpatches.
> >this approach is like netpd started in the beginning, but it turned out,
> >that this adds too much complexity.
> >anyway, i think that these kind of problems shouldn't be solved in the
> >userspace, but in pd itself, since that is a general problem. it would
> >be interesting, if there is ever a chance, that pd loads patches without
> >dropouts or if this is impossible by design.
> yeah would be nice if pd could do that, but for the moment i have this need
> and i can't really do anything else than search for a userspace-solution,
> which i'm quite close (i think).
nice to hear. what about the other reasons for drop-outs? how do you
deal with them?
> i guess if i can do it in userspace, it is possible in pd itself.
possible is almost everything with software, but how much effort does it need? rewriting pd?
though i am not too much a techie myself, i hear voices saying, that
despite the upcoming multicore-processor, pd won't be able to do
threading in the near future (which would be necessary in order to make
use of the additional calculating power). from my understanding of
things, i'd say, that in order to avoid drop-outs on patch-load (or
file/audiosample-load), pd would require threading (please someone
correct me, if i am totally mistaken). afaik, pd-dev does already some
of it (e.g. when reading a soundfile into an array).
> >there are other similar
> >problems, that cause dropouts, which might be easier to solve like
> >dropouts on full network buffer or writing and reading files.
> yes indeed. can we hire somebody to fix maxlib/netclient (+server)
> maybe we should begin with collection money?
hm... i wouldn't want to involve money in that issue. let's ask the
community first, shouldn't we?
> cheers enrique
yo, mate. get inspired by the spirit of the closeness to the nirvana in
goa. peace and a deep pd-ooooooohhhm!
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
More information about the Pd-list