- chuck-dev - lists.cs.princeton.edu

Questions on class-checking and Objective C-like interfaces
by Andrew C. Smith 20 Oct '09

20 Oct '09

Chuck Devs, I brought up something like this a while back on the users list, regarding general modulation functions, but I'm wondering if it wouldn't be that tough to implement in a seriously reckless build of ChucK. In Objective C, you can have something take "(id)" as an argument, which basically means anything. The compiler leaves it up to the programmer to get things right, which allows great flexibility during run-time operation. I was thinking that ChucK could get this by basically just ALLOWING (not requiring) the option to not check class methods. This would allow code like: // begin fun void modFreq ( UGen a, UGen b ) { while (true) { if (BoolBus[0]) { a.last() + 440 => b.freq; 64::samp => now; } } } SinOsc mod => blackhole; SinOsc car => dac; spork ~ modFreq( a, b ); day => now; // end This code is totally possible in current ChucK versions (replacing UGen b with SinOsc b, of course) but what happens if you want to modulate something else, in another class but still with a freq method? You have to create all new functions, all the time. This isn't really a huge deal if you have a giant code library, but it's not like it's fun or anything, and you end up with tons of obscure functions, maybe public class static functions like "SinMods.freq( a, b )" in these endless trees (well, not endless--there aren't quite that many UGens). It seems like this could be possible by disabling the compiler warnings. Naturally, this could lead to huge disasters, which is why I feel like it should be made optional (and possibly hard to initialize, just to protect people from themselves). Is this possible? I imagine that it wouldn't be that hard to switch--build another version of ChucK with the specific checking features turned off, and call it chucknorton or some equally dangerous-sounding name. Then you just type chucknorton + crazymods.ck and you've got some universal modulation functions. Lots of list posts lately, so sorry if these are just totally off-topic or stressful for some of the (real) devs. Longer recessions make for better open source software, though. Andrew

1 0

Re: [chuck-dev] Compiling under FreeBSD
by benny 20 Oct '09

20 Oct '09

Hi Raimundo, I got chuck-1.2.1.2 (the cli program) working for FreeBSD 7.2 by disabling the gui stuff and some other changes. You can do the following to check it out: wget http://stridor.net/upload/chuck-1.2.1.2.tgz gtar -xzf chuck-1.2.1.2.tgz cd chuck-1.2.1.2 && wget http://stridor.net/upload/freebsd.patch patch -d src -u -p1 < freebsd.patch cd src && gmake freebsd # and as root (copies the binary to /usr/bin) gmake install It should work - at least on FreeBSD 7.2 Perhaps someone (you?) could review the patch and put it upstream / integrate it with chuck-1.2.1.3 I am not really familiar with C nor make, just did a bit trial and error (mixing of the MacOSX and linux-oss options) that happened to work. You need libsndfile on FreeBSD Hope that helps. Perhaps you want to make a regular port of it? Best Regards, Benny > Hello all! > > I prefer the FreeBSD 8.0RC1 audio drivers, which implements the UAA > (Universal Audio Architecture - yes, from Microsoft...) and then > things just works. > > In linux, I have experienced problems with ALSA and the new OSSv4 do > not serve me well. And I get evolved in a project that uses chuck, and > tried to compile it under my brand new OS. I have tried with > > make linux-oss > > Many errors as I expected, some of I dismiss. A list of they and the > solution:

2 1

Compiling under FreeBSD
by Raimundo Santos 18 Oct '09

18 Oct '09

Hello all! I prefer the FreeBSD 8.0RC1 audio drivers, which implements the UAA (Universal Audio Architecture - yes, from Microsoft...) and then things just works. In linux, I have experienced problems with ALSA and the new OSSv4 do not serve me well. And I get evolved in a project that uses chuck, and tried to compile it under my brand new OS. I have tried with make linux-oss Many errors as I expected, some of I dismiss. A list of they and the solution: - within the begining of makefile.oss: ifneq ($(CHUCK_DEBUG),) FLAGS+= -g -O0 endif ifneq ($(CHUCK_STRICT),) FLAGS+= -Wall endif Just commented out this lines. - within files with #include "sndfile.h": Non-system stuff normaly belongs to /usr/local in FreeBSD. So adding to CFLAGS -I /usr/local/include must work. Just a dream, because in fact I have to modify FLAGS to insert it. -within files with #include <termio.h>: This header do not exist in FreeBSD and, as Mac OS X have a root in it, I have modified the linux-only includes and ioctl() to work under FreeBSD, by copying the MAC way. -whithin util_hid.cpp: Wow! It is a good source of TODO work. Things here are suposed to be very "low level", as I presumed. I am wondering if I am right. Am I? By "low level" I mean very OS dependent. I am new into FreeBSD world, and never programmed under linux over the OS by itself, I've used to program over Qt, and programmed little things. As the comment says in the begining of util_hid.cpp, this is the interface with input/interaction devices. And it is different under the many Oses that exists. Removing util_hid.o from deps of chuck target in the makefile, all the others compile ok. And my question: how things are supposed to work in this source? How can I learn it? How can I translate it to FreeBSD? I thought abou creating a makefile.freebsd, but this questions must be answered (even by myself) before. Sorry, I am Brazilian and my English is not quite good yet ... =/ - but I hope you understand me and could help me. Many many many thanks, folks! raitech

1 0

Fwd: Oh no, I fixed it: log level bug.
by Andrew C. Smith 17 Oct '09

17 Oct '09

The first part, about it not compiling unless "-D__ALTER_ENTRY_POINT__ is added to the tag still stands. However, the other one, about the mini hanging does not. So, here's the issue: I had "Default Log Level" under Preferences -> Miscellaneous set to "10", which crashes it. It's like someone set the log level name to "Crazy" as a kind of decoy... (either way, maybe this option should just be disabled. I know it's supposed to have spectacular crashes, but this seems a bit overboard.) Andrew

1 0

BUG! miniAudicle compilation on Xcode, and anything involving Snow Leopard (maybe?)
by Andrew C. Smith 17 Oct '09

17 Oct '09

1. The Xcode file seems to be missing chuck_shell.cpp. This turned out to be an issue, for some obscure reason. 2. I had to add the flag -D__ALTER_ENTRY_POINT__ to the build of the miniAudicle target, because it kept saying that _main was defined twice. It was, with one time in chuck_main.cpp and another in main.cpp (the miniAudicle main() routine). Both of these worked to make the program compile, but when I started it up and tried turn on the VM the whole program froze. I'm on Snow Leopard, but this happened when gidora came out. Everything worked just fine for the previous version, and it even worked when I replaced the chuck source with my own code and ran hacked versions. My initial thought is that maybe there is some tag somewhere that defines things asking if the system is 10.5, and so 10.6 just fails to register. But then, not even the downloaded binary works for me. I probably could have brought this up right when gidora came out, but it just slipped my mind. Any ideas, and other experiences with Snow Leopard and the mini? For the record, ChucK works just fine. I'm thinking it has something to do with the two main() declarations, since it doesn't crash until I start the VM, but who knows. Andrew

1 0

WvOut clipping patch
by Tom Lieber 17 Sep '09

17 Sep '09

Anybody interested in reviewing my patch to fix WvOut clipping? I try to make it clip instead of wrap around for int WAV formats. I tested it with WvOut's default WAV format, but I patched the others in a similar way so they might work as well (anybody use them?). http://github.com/alltom/chuck/commit/eb34928fbace9a0617814f766268fd8b929b6… The patch is against 1.2.1.2. -- Tom Lieber http://AllTom.com/

1 0

Updating ChucK's MIDI support
by R. Steven Rainwater 17 Sep '09

17 Sep '09

I need some additional MIDI features in ChucK for my application. I've already added code to support a MidiOut.progchange(channel,patch) method. Before I get too far along, I thought it would be a good idea to compare notes with the ChucK developers and see what the future plans are for MIDI support. I see in the Wiki the following note about features being debated for the next version: "Make MIDI more friendly, using named functions instead of numbers like was done with the HID, as discussed (Kas)" Also in the "Ongoing Feature Request" page: "Turn MIDI .msg parsing into a system of functions like was done with the HID (".isNoteOn()", ".isControlerChange()", etc) especially with a eye towards future incorporation of clock mesages and so on." This is basically where I'm going to. Initially I needed the progchange() function but I noticed while implementing it that a lot of this functionality is already present in the lower levels of ChucK (e.g. midiio_rtmidi.cpp and rtmidi.cpp). All I had to do was complete some work that was mostly done in the low level files and then add the progchange() method in chuck_lang.cpp. I think it would be easy enough to add other functions that appear to already existing lower down like polypress(), pitchblend(), allnotesoff(), noteon(), noteoff(), etc. I don't need all of that for my app but would be happy to continue working on it if it's something that's needed by other ChucK users. But if I do that, it would be nice to get some feedback on what method names the dev folks would prefer to see used in the ChucK VM. On the other hand, if this work is already under way by someone else, I don't want to step on any toes or release a patch with conflicting MIDI methods. Any thoughts on the best way to proceed? -Steve http://www.ncc.com/humans/srainwater

5 7

more GCC issues.
by Kassen 16 Aug '09

16 Aug '09

Fellow chuckists, Today there were some posts on the forum here; http://electro-music.com/forum/viewtopic.php?t=36259 about compiling ChucK on Fedora. It looks like the default configuration doesn't work (anymore, I really think it used to) on that platform, at least not without tweaking the optimisation. This could well mean that GCC was again updated with more strictness. Fortunately steevithak was able to document the cause and provide a workaround (see link). This might be worth some attention, I think Fedora is quite agressive about getting new things in (they are at GCC 4.4.0 while I've got 4.3.3 here as part of the default stable Ubuntu release) so this may well be a advance warning for the issues more Linux users are going to get once other distro's switch to a newer GCC; for a fair percentage of Linux users ChucK will be the first time they have to use GCC. Yours, Kas.

1 0

mini Vs GCC
by Kassen 27 Jun '09

27 Jun '09

Dear list, On the forum there was just another question about the current canonical Mini refusing to compile on a new Ubuntu install. I believe that issue is caused by the new GCC which refuses to deal with 1.2.1.1 and 1.2.1.1 still being included in the Mini source. I respect that Spencer is a busy man and doesn't always have the time to bake fresh versions of the Mini. However there is the easy trick of replacing the 1.2.1.1 source with the 1.2.1.2 one in the relevant directory of the Mini source. This makes it compile just fine and generally results in a preferable version. I have been using that version for quite some time now and am unaware of any bugs in it beyond those found in plain ChucK and the latest Mini. I'd like to propose as a temporary solution that we simply pull this trick on the version provided on the site instead of all individual users having to do it at home after running into errors and asking questions. It shouldn't take more then 10 minutes for somebody who has access to the server(s) and as far as I can tell it's as safe as anything ChucK-related is likely to ever be. No knowledge of C++ is needed, just a willingness to mis-label 1.2.1.2 as 1.2.1.1 as the version of ChucK is encoded in the dir name that the Mini's own source references. I think the Mac version was already patched(?) and suspect that the Windows executable could be treated in the same way with the same ease but I haven't personally verified that. While such treatments would be preferable the situation on those OS's isn't of the show-stopping nature as the current Linux one is. Yours, Kas.

1 0

cvs repo
by Stephen Sinclair 06 May '09

06 May '09

Hi, Just wondering, there seems to have been no activity in the CVS repo since last October. Is it just because there's no interest / time, or has development moved elsewhere? Steve

3 6