Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve 264.sfplay~ sound file loading #10

Closed
delucis opened this issue Sep 30, 2016 · 0 comments
Closed

Improve 264.sfplay~ sound file loading #10

delucis opened this issue Sep 30, 2016 · 0 comments
Labels
Milestone

Comments

@delucis
Copy link
Member

delucis commented Sep 30, 2016

Currently files are loaded into an sfplay~ object using the open message. Any file loaded — including from the drop-down menu — has to be read from disk every time. The delay before a file is fully loaded makes play messages fail if they arrive before the file finishes loading.

Preloading all files in soundfiles/ into an sflist~ would alleviate that delay. However, each 264.sfplay~ module would load its own independent sflist~ (although they would all be identical, there is no way to share sflist~ names to consolidate the memory usage). This, coupled with a potentially large number of sound files, might create a heavy demand on available memory.

Another solution might be to introduce an internal buffer for messages that depend on files being loaded. When a file starts loading, the play/stop/pause input might be cached temporarily and only fed through to the internal sfplay~ once the file is loaded. (Or, if that is impossible to detect, using defer?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

1 participant