posted 30 June 2006 18:04            

ORT.kym

It seems like your sound is asking too much for one dsp.
Even if you make some arrangements in order to change the scheduling, the processing power asked by the LiveSpectrumAnalysis and the sum of the 3 GrainClouds is too much.
I have made a variation of your sound (sorry, I could help myself of making it stereo !) that lowers the computation with a bunch of changes :
- changed the live analysis to analyze only 32 partials and changed the FilterBank number of filter accordingly
- changed the number of simultaneous grains from 28 to 10, which is the max possible. The script helps to change the values of the 3 GrainClouds all together.
- the "global" memory writing in the MemoryWriter was also a condition that forced the scheduling in a bad way I think, so I unchecked the option.
- I removed an unnecessary Gain module (but it is not a really important I think)

posted 30 June 2006 20:00            

Thanks for your reply! I understand that you can adjust things to make it less computationally expensive, but what was really bugging me about that sound is the fact that it works fine with the extra mixer at the end, but if you remove the redundant mixer it doesn't work anymore! At least on my capy it works ok the way I sent it, as long as I don't remove the last mixer. That seems a little odd, don't you think? Is there any reason for this?

Oh, and the gain was just to boost the level of the clouds a little after the filters close. It needs to be a gain sound though, because otherwise the level won't really go up as I need it, even if on the vcs it appears to do so. Actually, I thought that scale fields clipped at 1, but now that I tried it on the StereoMix4 the level does seem to go up for a bit when you go above one on the vcs (even though it won't accept a number above 1 if you type it directly in the parameter field), though not as it would with an actual gain sound. (?)

Thanks for your help!

Cheers,

posted 02 July 2006 17:06            

FuzzyGranulator.kym

During the last KymaSupport/iChat session, Carla and Kurt did give me the suggestion of duplicating the MemoryWriter thrice in order to schedule the SampleClouds differently. It proved to be a good solution as on my Capy, I can now run your sound with 28 grains as in your original example.

I have tried to dissociate the LiveSpectralAnalysis by applying the same kind of trick, but it gives me a wrong result. I'd be happy if someone could explain me why the fourth MemoryWriter samples wrong data !

In the attached file, you'll find an updated version of the Live Granulator and a version that is not working, but that would be interesting to figure out why ...

posted 02 July 2006 22:07            

That's an interesting solution! I guess that's part of the game when working with parallel processors, but if I understand correctly this allows each cloud to be scheduled on a different processor along with its respective buffer from the memory writer. The original version worked for me, but of course, only with the global box checked. I guess using the different writers saves you from having to write the sample in all the other processors as you would when checking global.

As for the non-working version, I have no idea why it does that, but last year I had a similar problem when I was using several writers at the same time. Some of the samples just wouldn't read properly, and I think Carla said that the compiler was getting confused somehow. But it might be a different issue, as I seem to remember that in that case it didn't happen consistently. I'd be curious to know what they say about this one though. And I am STILL puzzled by that extra mixer fixing the problem in my original sound! SSC?

Cheers,

posted 03 July 2006 10:14            

1. The compiler is NOT confused by multiple memory writers!
2. The compiler is a deterministic machine; thus it behaves consistently on repeated runs over the same data :-)

Having said that, one needs to be careful when using multiple memory writers, ensuring that each memory writer has its own distinctly named chunk of memory and that each writer is paired with at least one reader.

As I recall the problem with Hector's Timeline was that he had a MemoryWriter writing a chunk of memory that was never read. The compiler detected that this chunk of memory was no longer needed (because it was never referenced) and allowed a different MemoryWriter to reuse that memory. We have since corrected the problem so if you are using the latest update of Kyma you will not have this problem even if you accidentally forget to read a chunk of memory that you've written.

posted 03 July 2006 10:30            

What was happening is that the Sample was being read only once, for a duration of 1 second. If you have a cyclic MemoryWriter and you have given it a CaptureDuration of 1 second, then in most cases you would also want the reader to be cyclic (e.g. a Sample with SetLoop checked, an Oscillator, a FunctionGenerator with a repeating trigger).

posted 03 July 2006 11:21            

I was definitely getting inconsistent behavior, but it must have been due to something else I wasn't doing consistently with that particular timeline. I guess my head's compiler was the one getting confused. I didn't mean to imply that several writers would confuse the compiler, as that is something that I use often and it never happens. And not that I would know anything about how the compiler works, but I just remember some comment having to do with that. I apologize for the confusion.

posted 03 July 2006 11:24            

Don't be sorry about that, it's my fault !
I wrongly assumed that the reader didn't needed to be cyclic even thought the writer was.
I will listen to the corrected version and tell if it's ok.

posted 03 July 2006 11:26            

"Switching the source of a wavetable between MemoryWriter or file on the disk was confusing the Sound compiler in Kyma. We have fixed the compiler for the next update of Kyma."

So that's where the inconsistency was coming from! Once again, sorry for the confusion.

Cheers,