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

[Gary Scavone]

Hi Patrick,

The Voicer class is relatively simple and to keep the code “simple”, we placed a number of “burdens” on the user, including instrument allocation and deallocation. Large portions of the code assume that all voices added are valid.  It is not truly thread safe.  I’d say the only thing you could do (without changing the class code) is make use of some mutexes to make sure you aren’t trying to iterate over instruments that have been deleted.

—gary

> On Aug 22, 2015, at 1:35 PM, 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
>>