[Stk] How can you have a large amount of polyphony with STK?

[Gary Scavone]

Hi Patrick,

I would focus on the FileWvIn and FileLoop classes.  They need to be changed so that if the file size being read is smaller than the chunk size, the entire file is read and then the file is closed.  Currently, the file remains open because there are a few possible subsequent calls to the FileRead class to get things like the file size.  But this doesn’t need to happen, as the file size can easily be stored in a FileWvIn class variable.

This approach won’t take advantage of the cases where the same file is read many times (many instances of FileWvIn with the same file), but at least it fixes the problem of too many files being open.

Regards,

—gary

On Sep 8, 2015, at 10:31 PM, Patrick J. Collins <patrick at collinatorstudios.com> wrote:

>> I suggest giving it a shot yourself.  It shouldn’t be too hard to
>> figure out.  I have too many things going on with the start of the
>> academic year and I doubt I will have a chance to look at it until at
>> least October.
> 
> I am happy to do this, but I want to make sure the work I do is in
> alignment with your choices for design, etc.  I would hate to spend time
> on this to find that it's done in a way that goes against your goals of
> the library.  I have very little context on the approach taken to build
> these components.
> 
> Off the top of my head, an approach I would go with to solve this
> problem would be to give the Voicer an internal hash object which can
> store filenames as keys and the corresponding stkFrames array as its
> value, in otherwords, preload all the frames of the wave file into
> memory.
> 
> Then when an FM Instrument is added to the voicer, it would instantiate
> a simple object which would have stkFrames and tick().  So the FM
> instrument would use this instead of the FileLoop object, but tick()
> would allow it to conform to the same interface.
> 
> The goal of this design is so that a wave file will only ever be read
> from disk once, everything else after that would be completely in
> memory.
> 
> ....
> 
> That's off the top of my head how I would solve this problem, but again,
> I have no idea if this sort of thing would go against the design
> patterns of the project, and I don't want to spend time on something
> that would not be well received.
> 
> Please give me your feedback.
> 
> Patrick J. Collins
> http://collinatorstudios.com_______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/stk