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

Gary Scavone gary at ccrma.Stanford.EDU
Tue Sep 8 08:25:12 PDT 2015 

Hi Patrick,

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.

Regards,

—gary

On Sep 8, 2015, at 11:17 AM, Patrick J. Collins <patrick at collinatorstudios.com> wrote:

> Hi, I was just wondering if any progress has been made on this yet?
> 
> Patrick J. Collins
> http://collinatorstudios.com
> 
> 
> On Sun, 23 Aug 2015, Gary Scavone wrote:
> 
>> It appears that I wasn’t concerned with keeping the file open when I wrote the code.  And, it probably simplified the code in the case where were are incrementally reading file data (chunking) to always leave it open.
>> 
>> It is true that the file does not need to stay open unless we are chunking but I see various things in both the FileWvIn and FileLoop classes that would need to be fixed before that can happen. It would require some dedicated time to fix it without causing new bugs and I’m not sure when I’ll have that time.  If someone else wants to take a shot at it, let me know you are working on it so I don’t duplicate the effort.
>> 
>> Regards,
>> 
>> —gary
>> 
>>> On Aug 23, 2015, at 7:27 PM, Perry Cook <prc at CS.Princeton.EDU> wrote:
>>> 
>>> Aha!  Chunking likely might be causing this.  No need to chunk such short
>>> files.  I checked this, but it seems chunking is not true, but yet the file still
>>> has to stay open for this class to work correctly.  Still working on it.
>>> Any insights from Gary or others would be helpful.
>>> 
>>> PRC
>>> 
>>> 
>>>> On Aug 22, 2015, at 1:23 PM, Perry Cook <prc at CS.Princeton.EDU> wrote:
>>>> 
>>>> 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
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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

More information about the Stk mailing list