[PD] singleton in pd (was: problems with bandlimited_oscillators)

[Roman Haefeli]

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
> 
> 
> _______________________________________________
> PD-list at iem.at 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