Hi,
I've found out that Pd takes a lot longer to load big patches when run without the -realtime option (or if you prefer, it is a lot faster in loading patches if run with the -realtime option). "A lot" means an order of magnitude and a half. This is on Linux. Does this happen on Mac too?
I guess this is because realtime gives it a higher overall priority, but I wouldn't expect this to affect the loading of patches, would you? I don't know if anything can be done about this, but _if_ it can, I think Pd should try to load a patch as fast as possible regardless of whether it is in realtime mode or not. Couldn't it "acquire" this higher priority (the way it does when launched with -realtime) temporarily before loading a patch and then "release" it? Or is that a static thing that can only be determined at startup?
Just some thoughts
Cheers m.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-21 11:43, Matteo Sisti Sette wrote:
I guess this is because realtime gives it a higher overall priority, but I wouldn't expect this to affect the loading of patches, would you? I
no, i wouldn't have guessed that either.
don't know if anything can be done about this, but _if_ it can, I think Pd should try to load a patch as fast as possible regardless of whether it is in realtime mode or not. Couldn't it "acquire" this higher priority (the way it does when launched with -realtime) temporarily before loading a patch and then "release" it? Or is that a static thing that can only be determined at startup?
but what is the point of "realtime" then?
with the same argument you could say: in realtime mode i get far less audio dropouts; couldn't Pd temporarily switch to higher priority when turning on audio, and "release" it when audio is turned off?
you (the user) can choose between realtime and non-realtime, because both modes of operation have pros and cons. one big con of "realtime" is, that you can lock your machine completely. ignoring non-realtime mode can thus have serious implications.
fgamsdr IOhannes