From gary at ccrma.Stanford.EDU  Wed Feb  3 13:47:28 2016
From: gary at ccrma.Stanford.EDU (Gary Scavone)
Date: Wed, 3 Feb 2016 16:47:28 -0500
Subject: [Stk] How can you have a large amount of polyphony with STK?
In-Reply-To: <4E4155FB-4D70-44B3-88D2-2D2EA1064C5E@cs.princeton.edu>
References: <alpine.OSX.2.11.1508212249380.47113@darius.westell.com>
	<6FD8D225-E737-4457-BD39-95C616665FAE@ccrma.stanford.edu>
	<alpine.OSX.2.11.1508221019500.57017@darius.local>
	<0AEE670D-2050-43ED-9A10-449CC4F1A791@cs.princeton.edu>
	<5D94B57D-FB71-44ED-84BD-7576DC54D4EF@cs.princeton.edu>
	<4E4155FB-4D70-44B3-88D2-2D2EA1064C5E@cs.princeton.edu>
Message-ID: <BDAF13B5-F09B-4EE3-9C79-9640064B5E18@ccrma.stanford.edu>

I fixed this problem and pushed it to the git repo (https://github.com/thestk/stk). I did a few different tests but it would be good if others could give it a try too.

I?m going to try to wrap-up some updates to RtMidi and RtAudio before making a new release of STK, but hopefully that won?t take more than a few weeks.

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