same questions, but asked with fewer sentences: how to implement a singleton pattern in puredata, that also works, when arbitrary instances are closed or deleted?
roman On Thu, 2007-03-22 at 21:40 +0100, Roman Haefeli wrote: > hello > > i've overseen a big problem with the bandlimited_oscillators > -abstractions, which syntax_tn pointed to. > when the bl oscs are used in several patches and the patch, that was > loaded first, is closed, the other patches' oscs won't work anymore, > because the first patch was the parent of the singleton, that contained > the tables. i didn't think about that when implementing. > > i see some options to come around that, but none of them is really nice: > > - the instance, that contains the tables, could send a 'ping' in a fixed > intercval and as soon as the ping is not received anymore by the other > instances, one of them creates the tables. the problem is, that it > causes possibly a lot of errors in the time before the new tables are > created. and sending ping-messages regularly is not nice anyway. > > - localize the the actually global tables. every synth has its own > tables, so that it doesn't matter, when a synth is closed. it has two > disadvantages: it uses more memory for the tables, because the might be > created several times. also it causes heavier dropouts when a patch is > loaded, because on each patch-load, that contains bl oscs, the tables > are created. > > - the user has first to load the bl*_tables-abs in order to create the > tables in advance, before the oscillators are loaded. this needs > additional user action, which is suboptimal > > - the first instance opens the patch, that creates the tables. the > others check, if the tables are already 'on'. the table creating patch > could be opened hidden by sending it a [vis 0( after opening. this > approach needs no additional user interaction, the tables are created > only once and it doesn't matter, when patches are closed. BUT: besides > that this approach seems to look a bit workaroundish and ugly and the > table creating patch remains open until pd is closed, it can't be > implemented without externals (getdir) or it needs an additional > configuration file to specify the path to directory, where the table > creating abs are located. the problem here is, that the [open(-message > to pd wants a path relative to the startup-location (whereas > file-loading objects want a path relative to > the patch-location). > > everyone of these approaches would work a bit, but none of them is THE > solution. any other ideas? > > thanks in advance > > roman > > > > > > > > ___________________________________________________________ > Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: > http://mail.yahoo.de > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
