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

[Perry Cook]

Well crap.  I just tried this and it turns out that for some inexplicable
reason FileLoop (possibly in its name) seems to need to keep the file
open.  Things don’t work (in a very bad way)  if I add the closeFile at
the end of the openFile routine.  Data seems to be read into an array,
so I can see no reason to keep the file open.

Gary, is this the way things work?

PRC


> On Aug 22, 2015, at 12:56 PM, Perry Cook <prc at CS.Princeton.EDU> wrote:
> 
> Those files shouldn’t be open for long, just long enough to read them
> once, then close it up.  The UGen doesn’t keep reading from the file,
> but uses a table that was filled from the file.  
> 
> I just checked Rhodey which uses FileLoop to read and store the 
> sine/other wavetables, and note that the beginning of FileLoop:openFile
> calls close for safety:
> 
> void FileLoop :: openFile( std::string fileName, bool raw, bool doNormalize )
> {
>  // Call close() in case another file is already open.
>  this->closeFile();
> 
> then opens the file in question.  BUT, it should really close it at the end
> of this routine, since it’s been read and never used again.
> 
> Try adding this->closeFile() to the end of this openFile routine.
> Let us know if this fixes things.   Gary, if so, we should make this
> modification.
> 
> PRC
> 
> PS:  One other possibility is that the OS takes a bit of asynchronous
> time to actually close files and clean up, so your tight loop of
> opening 64*4 (four for each Rhodey) files at essentially instantly
> might be clobbering things.  Since you likely do this once at setup
> time, you might consider a slight delay between each time around
> the loop.  sleep(100) or some such?
> 
> 
>> On Aug 22, 2015, at 10:35 AM, Patrick J. Collins <patrick at collinatorstudios.com> wrote:
>> 
>> Hi Gary,
>> 
>> I think it probably has to do with the number of files that can be open at a
>> given time..  This is running on an iOS platform.  But definitely, this
>> code:
>> 
>>   for (int i = 0; i < 64; i++) {
>>       Rhodey *rhodey = new Rhodey();
>>       delete rhodey;
>>   }
>> 
>> will crash with:
>> 
>> FileRead::open: could not open or find file (../../rawwaves/sinewave.raw)!
>> 
>> But if I change 64 to something like 32, then it's fine...  But this is a huge
>> problem for me because there are many cases where this *might* crash on me,
>> since I am using STK in a very dynamic way.
>> 
>> http://stackoverflow.com/questions/18666921/maximum-amount-of-open-files-on-ios
>> 
>> That's why I thought it would be so much better if STK was just preloading a
>> shared table that the instruments could all read from in memory since they're
>> so small, and not have to have any unnecessary disk IO.
>> 
>> ....  Separate topic:
>> 
>> The other problem I have found is that voicer->tick() doesn't seem to check if
>> the current instrument has been removed or not.
>> 
>> So, I have an OpenAL loop which is running in a separate thread which is just
>> calling voicer->tick() over and over and over...
>> 
>> The in my main thread, I will play an instrument, and then be done with it by
>> doing:
>> 
>> rhodey->noteOff(rhodeyTag, rhodeyAmplitude);
>> voicer->remove_instrument(rhodey);
>> delete rhodey;
>> 
>> ...  This will eventaully crash my applcation as well, because I am assuming,
>> my other thread is in the middle of calling voicer->tick() and the voicer is
>> iterating over frames and waves, and then suddenly delete rhodey is called, and
>> it's now trying to iterate over waves that were just deallocated-- crash!
>> 
>> I would think voier should be looking to see if the current instrument is
>> actually attached to the voicer before calling tick on it to prevent this sort
>> of problem.
>> 
>> The only solution I could think of to prevent the crash is to delete the
>> instrument after a 1 second delay, but that feels like a horribly unreliable
>> fix.
>> 
>> Do you have any suggestions?
>> 
>> 
>> Patrick J. Collins
>> http://collinatorstudios.com
>> 
>> 
>> On Sat, 22 Aug 2015, Gary Scavone wrote:
>> 
>>> If it was just a sinewave, then the SineWave class is the answer (it creates a static sine table).  But in the case of the FM instruments, the table is often not sinusoidal.  So, I don’t have a quick fix for that.
>>> 
>>> I don’t see why loading very small tables should cause a crash.  It is likely some other, potentially related, issue or bug.
>>> 
>>> —gary
>>> 
>>>> On Aug 22, 2015, at 1:52 AM, Patrick J. Collins <patrick at collinatorstudios.com> wrote:
>>>> 
>>>> It appears to me that everytime an instrument (FM) is instantiated, it
>>>> is reading the sinewave waveform from disk, and if I want to have a
>>>> large amount of polyphony:
>>>> 
>>>> Voicer *voicer = new voicer();
>>>> int group = 0;
>>>> for (int i = 0; i < 64; i++) {
>>>>  Rhodey *instrument = new Rhodey();
>>>>  voicer->addInstrument(instrument, group);
>>>> }
>>>> 
>>>> ...
>>>> 
>>>> My application crashes when doing fopen that many times...  Is there a
>>>> different way to get polyphony than this?  Is there an easy way to share
>>>> the same sinewave with multiple instances of an FM instrument?
>>>> 
>>>> Patrick J. Collins
>>>> http://collinatorstudios.com
>>>> 
>>>> _______________________________________________
>>>> Stk mailing list
>>>> Stk at ccrma.stanford.edu
>>>> https://cm-mail.stanford.edu/mailman/listinfo/stk
>>> 
>> _______________________________________________
>> Stk mailing list
>> Stk at ccrma.stanford.edu
>> https://cm-mail.stanford.edu/mailman/listinfo/stk
> 
> 
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/stk