<div class="gmail_quote"><div>Gabor;</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">PathFromScheme is a helper function that we can use when developing modules in c++.<div class="im">
<br></div></blockquote><div><br></div><div>Check. that's outside of my scope then.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
i'm not really familiar with the audio functions, but it's quite straightforward to change any functions from strings to paths.<br><br></blockquote><div><br></div><div>I think Fluxa's usage of .wav files for samples is not unlike .png files for textures. They are loaded from a path/string and I'm 99% certain that once loaded they are buffered with re-loading not having any effect until we flush the cache. Aside from us not using dedicated memory on a card, like with graphics, I think those files are like textures in a lot of ways and should be treated as such if we change the way we load textures from the drive, syntax-wise.</div>
<div><br></div><div>Again; especially because there too it might make sense to load a whole dir worth of samples in one swoop, or wonder whether a certain file exists. The same goes for OpenAL, BTW. If it's relatively little effort and has no chance of breaking stuff or causing overhead then I'd say the fluxa and OpenAL calls for .wav files need this.</div>
<div><br></div><div>Yours,</div><div>Kas.</div><div><br></div><div>PS I could imagine that in the future we might like the option of re-loading just a single texture or sample, based on polling the OS for the "changed" time. This would save flushing the cache and pumping around tens or hundreds of MBs of data for a single update. I think that path support makes such polling a lot easier, but I'm working from memory here. Restarting Fluxus takes away from the process (which may not involve saving at all, in our scene) and undue breaks&hickups aren't our style.</div>
</div>