eduard aylon wrote:

Hi Kassen,

...

That's just plain wrong, the Mini can produce lots of sound.

I am sure it's wrong, that's why I said I was missing something. It's too obvious not to work..

To be perfectly clear; I meant to say it was the Mini that was wrong, not you. This came out very clumsily due to editing that line in a bit of haste. I hope this didn't look offensive but upon rereading I have to admit that it quite likely did. Apologies.

Ok. I checked the settings, which I didn't do before (stupid, yes I know). Now it works, but still something not quite right happened. First scenario: not working sr=44100, buffer_size=256, soundcard= apple's mic input and apple's build-in output. Second scenario: stopping virtual machine and restarting it worked. sr=44100, buffer_size=256, soundcard= apple's build-in input and apple's build-in output. Third scenario: back to first scenario. stop vm and restarting it. This time worked ok.

I don't think it was all that stupid to overlook the settings as they are fairly new and besides, most of the time you don't need to touch them. What I find more troublesome is that I was suspecting something unusual was going on like a exotic soundcard or unusual Jack settings (you didn't mention your OS). Build in Mac cards at settings like that should just work and those strike me as particularly easy to find default settings for as they are so standard. Oh, well, it was worth a try to check the settings but that sounds like a real bug. It's still quite odd that something like this wouldn't surface sooner, maybe something is unusual after all? Yours, Kas.

Hi Spencer, works fine from now on. It seems as changing the settings may have done something. I will try tomorrow or soon in another computer where it has never been launched before and see if I can reproduce the error. Eduard On Oct 30, 2007, at 5:44 PM, Spencer Salazar wrote:

Eduard,

As Kassen mentioned all three of your scenarios should be rock solid, and miniAudicle shouldn't need any tweaking to work out of the box. Can you cut and paste the entire output on the console monitor after starting the VM in the scenario that isn't working? That will help me understand better what's going wrong here.

spencer

On Oct 30, 2007, at 12:56 AM, eduard aylon wrote:

...

Hi Kassen,

...

That's just plain wrong, the Mini can produce lots of sound.

I am sure it's wrong, that's why I said I was missing something. It's too obvious not to work..

...

My bet is that something is going wrong with the Mini's settings and connecting to the soundcard and the most likely candidate in my experience is sample-rate. I suggest having a look at the settings menu of the Mini and making sure that what's set conforms to your soundcard.

Ok. I checked the settings, which I didn't do before (stupid, yes I know). Now it works, but still something not quite right happened. First scenario: not working sr=44100, buffer_size=256, soundcard= apple's mic input and apple's build-in output. Second scenario: stopping virtual machine and restarting it worked. sr=44100, buffer_size=256, soundcard= apple's build-in input and apple's build-in output. Third scenario: back to first scenario. stop vm and restarting it. This time worked ok.

Thanks,

eduard _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 10/30/07, Peter Todd wrote:

Hello,

Can't one just have a public class that you load everytime you start chuck with a few static Gain objects to use as busses?

Yes, you could and I think it would be functionally equivalent, except that I imagined buses would pull samples (which could be done by using blackhole in the class anyway). What I'm after though is a more "casual" way of using buses for impulsive coding sessions. I'm not sure what it is; I know I can do things like that for additions to the syntax I know I could set up a little script to start ChucK for me and load all of those and hardly ever notice but somehow that doesn't seem so much fun. Maybe I'm just whining and should just do it?

p.s. apologies if this ends up as a double post; I accidentally sent it once on (gasp) my normal email address, but that one should be cancelled now.

Looks fine to me, thanks for your concern. Kas.

Martin;

No, I don't think you're just whining! Right now, chuck is built around the idea of having multiple programs synced together in time. It would be awesome if you could share more things between the programs. Public ugens, public variables, public events, and - as you said - busses.

Exactly. Public events for straightforward sequencing (in any sense of the word) would be great as well. We do have public classes and they are great for what they do but I dislike them for impulsive sessions as you only get to define them once so you can't extend them. Because the DAC already also works as a internal bus, in a way (dac => LiSa l => dac; //is fine) I imagine adding something called "bus" that operates exactly like a dac aside from not sending data to the soundcard should be a more or less straightforward addition. The one issue (difference) I see right now is that for the DAC we need to set the max amount of channels at startup but that might mainly be a matter of communicating with the soundcard. If we would have public Ugens the whole issue would become moot as you could simply go; public Gain bus1 => blackhole; But I wonder how hard that would be to implement. If it were easy we probably wouldn't have the current situation with static members of public classes.... Yours, Kas.