how many blackholes?

majutsu · Posted: Mon Sep 04, 2006 5:12 pm Post subject: how many blackholes?

in a piece of code, how many blackholes can run at the same time? just one? or, when shredding, how many blackholes can run at the same time, if each shred uses one blackhole?

ge · Joined: Aug 13, 2006 Posts: 108 Location: Palo Alto, CA

majutsu · Posted: Mon Sep 04, 2006 8:41 pm Post subject:

well, let's say i wanted to modify the frequency of one sine wave with another (fm), the modifier would use blackhole. Let's say then at the same time i want that whole sound to have a vibrato, another sine wave as a pitch lfo uses the blackhole. can they both function at once or do their numbers tangle in the blackhole. in the dac it doesn't matter because everything can play at once without wondering how it got there.

ge · Joined: Aug 13, 2006 Posts: 108 Location: Palo Alto, CA

Kassen · Posted: Tue Sep 05, 2006 2:58 am Post subject:

As I understand it it's a matter of execution order and saving cpu by not calculating unused Ugens.

I think that when a Ugen want's to calculate it's next output it first needs the outputs of everthing conected to it so it send "you calculate yourself first" to all Ugens conected to it and once those are done it calculates itself. As long as that chain would start sending it's requests at the end stage (the DAC) everything that gets heard oraffects something that gets heard will be calculate. The exception would be things that don't end up at the DAC yet still get used. For those Blackhole is used.

This means only one Blackhole would be enough; the important thing is only that it knows what's conected to it and that it asks those things to be computed.

Not only does that mean ChucK's calculation order would work roughly like Clavia's G2; It also means you could now trace in what order things get calculated which might be usefull for things like homebrew filters. This is cool because it means no uexpected artefacts from weird calculation order matters like in some systems.

Also; we realy need Blackhole; it wouldn't do to calculate everything the DAC needs every sample, then calculate stuff that normally doesn't get used only as a .last() function gets called. This is because the last sample of a ugen will depend on all that went on before it and so we couldn't save cpu that way; it'd just mean huge spikes in cpu usage every now and then.

To be clear; this is just how I think it works and what some of the reasoning behind it is, I could be wrong

kijjaz · Posted: Tue Sep 05, 2006 11:57 am Post subject:

do i understand correctly?.. in this case..
we can just do:

// ---
// oscilator initializations..
. . .
. . .

// let's say we have 2 lfos
triosc lfo1 => blackhole;
triosc lfo2 => blackhole;

// and let them make love
10::samp => dur controlrate; // just for this example
while(controlrate => now) {
lfo1.last() do something => with oscillator's something;
lfo2.last() do something => with oscillator's another something;
}

right?
see you around soon.

oh and .. how do i multichuck? i can't find a doc that has that example
but i think i've seen it before
is it something like.. triosc lfo1, triosc lfo2 => blackhole; ?

- kijjaz

Kassen · Posted: Tue Sep 05, 2006 2:56 pm Post subject:

Right, completely right.
Both lfo's end up at "blackhole", blackhole will make sure they calculate a value every sample and aside from that it doesn't do anything. It's kinda a abstract concept and not something where you have to considder how many blackholes it takes to fill a medium sized dinner plate. Having more then one blackhole might even cause execution order confusion, asuming my guesses above are right.

As for "multi chucking" I'm realy not sure. Ge will know but to me that sort of line sounds needlessly confusing. A while ago we had a small-ish issue with defing multiple Ugens that way (and not even chucking them anywhere), I din't lose any sleep over that bcause I don't realy see any advantage in that style of writing.

ge · Joined: Aug 13, 2006 Posts: 108 Location: Palo Alto, CA

Multi-chucking only works for function invocation:

kijjaz · Posted: Tue Sep 05, 2006 6:45 pm Post subject:

yes.. i just can't imagine
someone chucking 2 people
and those 2 people chucking another someone.

A chucking B and B chucking C or
A chucking B chucking C at the same time looks better for me

what the chuck -_-"
- - -

if i've chucked an oscillator or any other kinds of ugen to blackhole..
okay the values are going to be calculated..

but if i unchuck them..
would the value read from those ugens stopped also?
(i'll try to figure this out myself also) ..
- - - i'm back again

i've got this code to test:

Kassen · Posted: Wed Sep 06, 2006 12:39 am Post subject:

Never mind, we have a bug on the board with representing code, I'm sure that last paragraph was right but the board mucks it up, something to do with triniangular brackets. I'm going to report this to Mosc.

This realy sucks.

kijjaz · Posted: Wed Sep 06, 2006 1:35 am Post subject:

ahh.. sorry i didn't checked it yesterday.
i've corrected the code.
i just forgot to check [ ] Disable HTML in this post
sometimes < > in the code make it confused with html tags.

Kassen · Posted: Wed Sep 06, 2006 2:47 am Post subject:

Wait! That's it!

I thought the [] was to *enable* HTML. My bad.

Ok, I'll post this to the intro post and switch it in my settings.

thanks!