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 frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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@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
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
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?
The bug, syntax noted, is a known one of the singleton implementation developed on this list. Of course the simple workaround is to never close the patch that created the singleton(s). You can look for this by watching the outlet of singleton.pd IIRC.
Yes, that's a crude suggestion, but as long as we don't have a real closebang I don't see a solution to decrement the instance counter [value] if an objects is deleted and create a new one, if the counter has reached 0 again.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Roman Haefeli