Author |
Message |
NeKro_Phyl
Joined: Jan 29, 2008 Posts: 11 Location: Berlin
|
Posted: Fri Feb 08, 2008 6:46 pm Post subject:
Clicks between (re)loaded programs |
|
|
Hi @all,
I've got a problem with Chuck - ok, its not really with chuck, it's with my Mac Book.
When I play a Program with chuck and load another Prog in the VM (or reload the same Prog in it with = 1 name.ck), I hear a short click between the two sounds.
I tried SuperCollider whether I can work there without that click but I also hear it there, so I think something with the configuration with my soundcard is wrong.
That could of course be, as I still use the vanilla-Configuration made by apple (I once set up a JACK audio Server but I don't use it).
So, can anyone help me? |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Sat Feb 09, 2008 6:54 am Post subject:
|
|
|
I don't think we can blame Apple for this.
Not even a multinational their size can prevent clicks if you suddenly stop one sound and at that very moment start another; unless some sort of cross-fading would be used the wave-form will jump from one value to another and this will result in a click.
Depending on you CPU's speed there may be more artefacts; at that moment the CPU will be quite bussy translating your code into something that will run in the VM and all cycles it uses on that are unavailable for generating sound. This can lead to glitches as well and of course so does the allocation of resources for your new code (if it's big), the loading of sound files, etc. _________________ Kassen |
|
Back to top
|
|
|
NeKro_Phyl
Joined: Jan 29, 2008 Posts: 11 Location: Berlin
|
Posted: Wed Feb 13, 2008 3:55 pm Post subject:
|
|
|
Ok, as far as I can see, I don't have these problems if I spork the programs. Ok for me, so nor, for example if I want to modify this really complicaded ( )Program on the fly
Code: |
//This Program is called Tester.ck
SinOsc s => dac;
while(1){
300 => s.freq;
1::second => now; }
|
I write a Meta-Program:
Code: |
while( true )
{
// This Program is called Tester2.ck
Machine.add( "../Tester.ck" ) => int Tester;
1::second => now;
Machine.remove( Tester );
}
|
Where Tester.ck is our little sine-oszillation above.
Now I am thinking to build another Meta-Prog, so that I can modify the code above, for example add some other shreds. But if I write sth like this:
while( true )
{
Machine.add( "../Tester2.ck" ) => int Tester2;
1::second => now;
Machine.remove( Tester2 );
}
the shreds dont get canceled the way they should. I experimented a little bit with the timing changing the 1::second in the code above which changes the programs behaviour:
time für shred Tester2.ck > 1::second:
Code: |
[chuck](VM): sporking incoming shred: 1 (Tester0.ck)...
[chuck](VM): sporking incoming shred: 2 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 3 (Tester.ck)...
[chuck](VM): removing shred: 3 (Tester.ck)...
[chuck](VM): sporking incoming shred: 4 (Tester.ck)...
[chuck](VM): removing shred: 2 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 5 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 6 (Tester.ck)...
[chuck](VM): removing shred: 6 (Tester.ck)...
[chuck](VM): sporking incoming shred: 7 (Tester.ck)...
[chuck](VM): removing shred: 5 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 8 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 9 (Tester.ck)...
[chuck](VM): removing shred: 9 (Tester.ck)...
[chuck](VM): sporking incoming shred: 10 (Tester.ck)...
[chuck](VM): removing shred: 8 (Tester2.ck)...
|
for time <= 1 second
Code: |
[chuck](VM): sporking incoming shred: 1 (Tester0.ck)...
[chuck](VM): sporking incoming shred: 2 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 3 (Tester.ck)...
[chuck](VM): removing shred: 2 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 4 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 5 (Tester.ck)...
[chuck](VM): removing shred: 4 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 6 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 7 (Tester.ck)...
[chuck](VM): removing shred: 6 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 8 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 9 (Tester.ck)...
[chuck](VM): removing shred: 8 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 10 (Tester2.ck)...
[chuck](VM): sporking incoming shred: 11 (Tester.ck)...
|
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Feb 13, 2008 4:32 pm Post subject:
|
|
|
Indeed, that shouldn't give clicks because you are using a integer amount of Hz for your frequency so the osc will always be at a positive zero crossing when the shred is replaced.
While this is a clever strategy I do think you'll run into issues with more complicated programs as we still don't have garbage collection. I'd look for a way to replace the shred only when a new version is ready, for example by using a hotkey. _________________ Kassen |
|
Back to top
|
|
|
kijjaz
Joined: Sep 20, 2004 Posts: 765 Location: bangkok, thailand
Audio files: 4
|
Posted: Fri Feb 15, 2008 6:00 am Post subject:
|
|
|
I also have a problem with this issue:
sometimes I want to replace a shred in a smoother way..
I really want some comfortable way to have a "central system / shred" that do the communication between shreds.
I've noticed that a static class can do such a thing but it's not dynamic enough and we can't define many types of that in its variables.
One thing that might work for that might be a center shred with OSC capabilities
(but I haven't practiced using OSC yet! .. I should soon)
And let's say.. we have a program that'd produce a loop.
(so simply 'replacing' will make a click impulse, which is we're avoiding now)
Rather than replacing by hand,
I might want to have some center system that'd keep counting the loop shreds of that type..
and when adding a new shred, it can automatically remove older shred so that the new sound will replace at the appropriate moment..
(and the way to safely kill the old shred might be sending a message (OSC?) to the older shred so it can prepare to terminate itself smoothly.
This is what I think is gonna be useful and quite simple in terms of code.
And easy to use because only "add new shred" is what we need to replace.
I'm gonna start implementing soon
(notice that i'm quite lazy these days..
I've been saying lots of things I should have practiced.. but mainly not many codes are produced hahahah) |
|
Back to top
|
|
|
|