March 2014 - chuck-users - lists.cs.princeton.edu

chuck vm options
by Al Matthews 29 Apr '14

29 Apr '14

Hello list. 1) Catching up a bit, it occurs to me that shell%> chuck --start `while(true) 1::second +=> now;` has been superseded by shell%> chuck --loop ; correct? Does ChucK any longer accept subprocesses or so, from the shell? 2) Also if anyone cares to distinguish or give an example for --callback Utilizes a callback for buffering (default). --blocking Utilizes blocking for buffering. then I'm much obliged as this is unfamiliar in some respects to me. Al Matthews - http://fatmilktv.com Atlanta, GA, US +1 337 214 4688

3 2

workshopping (atlanta)
by Al Matthews 04 Apr '14

04 Apr '14

Hello again. I am undertaking as of next month a series of livecode workshops in Atlanta, in which I expect to teach or demo a fair amount of ChucK. I'd very much appreciate hearing what your teaching | learning experiences in ChucK may have been. I've mined a lot of existing ChucK material, but I certainly appreciate examples as well. Naturally I will give full authorship credit insofar as I receive it, to any borrowed examples. Thank you. Al Matthews - http://fatmilktv.com Atlanta, GA, US +1 337 214 4688

3 3

Float assignment totally unexpected
by alfredo 26 Mar '14

26 Mar '14

Hello everybody! I'm running miniaudicle for ubuntu 13.10. everything compiles and even sound works. i'm just facing an unexpected behaviors with floats. <<< 12.2 >>> prints 12.000000 : (float) <<< 1.2 * 2.2 >>> prints 2.00000 : (float) 2.3 => float a; <<< a >>> prints 2.000000 : (float) i really want to solve this out as soon as possible. any advices? is a gcc/g++ issue? is chuck language issue?

4 9

Build error in miniAudicle 1.3.1
by alfredo 19 Mar '14

19 Mar '14

Hello everybody! I'm facing this error when i do "make linux-alsa" on ubuntu 13.04: b4ts4rr4@blu3zy:~/Scaricati/miniAudicle-1.3.1/src$ sudo make linux-alsa qmake-qt4 "RTAUDIO_BACKEND=ALSA" -o makefile.qt-alsa miniAudicle.pro make -f makefile.qt-alsa make[1]: ingresso nella directory "/home/b4ts4rr4/Scaricati/miniAudicle-1.3.1/src" /usr/lib/x86_64-linux-gnu/qt4/bin/uic qt/mAMainWindow.ui -o build/ui_mAMainWindow.h /usr/lib/x86_64-linux-gnu/qt4/bin/uic qt/madocumentview.ui -o build/ui_madocumentview.h /usr/lib/x86_64-linux-gnu/qt4/bin/uic qt/mAConsoleMonitor.ui -o build/ui_mAConsoleMonitor.h /usr/lib/x86_64-linux-gnu/qt4/bin/uic qt/mAVMMonitor.ui -o build/ui_mAVMMonitor.h /usr/lib/x86_64-linux-gnu/qt4/bin/uic qt/mAPreferencesWindow.ui -o build/ui_mAPreferencesWindow.h /usr/lib/x86_64-linux-gnu/qt4/bin/uic qt/mAExportDialog.ui -o build/ui_mAExportDialog.h g++ -c -m64 -pipe -D__LINUX_ALSA__ -D__CK_SNDFILE_NATIVE__ -D__LINUX__ -D__PLATFORM_LINUX__ -Ichuck/src -DHAVE_CONFIG_H -O3 -w -D_REENTRANT -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Ibuild -Ibuild -o build/mAMainWindow.o qt/mAMainWindow.cpp g++ -c -m64 -pipe -D__LINUX_ALSA__ -D__CK_SNDFILE_NATIVE__ -D__LINUX__ -D__PLATFORM_LINUX__ -Ichuck/src -DHAVE_CONFIG_H -O3 -w -D_REENTRANT -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Ibuild -Ibuild -o build/main.o qt/main.cpp gcc -c -m64 -pipe -D__LINUX_ALSA__ -D__CK_SNDFILE_NATIVE__ -D__LINUX__ -D__PLATFORM_LINUX__ -Ichuck/src -DHAVE_CONFIG_H -O3 -w -D_REENTRANT -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Ibuild -Ibuild -o build/util_xforms.o chuck/src/util_xforms.c g++ -c -m64 -pipe -D__LINUX_ALSA__ -D__CK_SNDFILE_NATIVE__ -D__LINUX__ -D__PLATFORM_LINUX__ -Ichuck/src -DHAVE_CONFIG_H -O3 -w -D_REENTRANT -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Ibuild -Ibuild -o build/util_thread.o chuck/src/util_thread.cpp g++ -c -m64 -pipe -D__LINUX_ALSA__ -D__CK_SNDFILE_NATIVE__ -D__LINUX__ -D__PLATFORM_LINUX__ -Ichuck/src -DHAVE_CONFIG_H -O3 -w -D_REENTRANT -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Ibuild -Ibuild -o build/util_string.o chuck/src/util_string.cpp chuck/src/util_string.cpp: In function 'std::string get_full_path(const string&)': chuck/src/util_string.cpp:393:14: error: 'PATH_MAX' was not declared in this scope chuck/src/util_string.cpp:395:42: error: 'buf' was not declared in this scope make[1]: *** [build/util_string.o] Errore 1 make[1]: uscita dalla directory "/home/b4ts4rr4/Scaricati/miniAudicle-1.3.1/src" make: [linux-alsa] Errore 2 (ignorato) any ideas how to solve? thanks best regards, alfredo

1 0

Eternal chuckation
by Stuart McDonald 15 Mar '14

15 Mar '14

I'm trying to get a continuous ambient mix 'app', where once a SndBuf finishes playback, another will be instantiated. There should always be two SndBufs playing at all times. I can get this scenario working easily enough but the memory used by earlier playback isn't being freed up. It seems that as long as a parent shred (required to instantiate and monitor the sndbufs) is while-ing away eternally, the sndbuf remains in resident memory. This is a problem because as more sound files are selected and played the computer will eventually run out of memory. Switching to the command line I find I can chuck + simple sndbuf playing files and once playback is complete, memory use goes back to what it was. I already have a perl script running to take care of environment and execution of the program on boot, so I can modify that to periodically add new chucks. The problem now shifts to knowing when to identify that the current file has completed playback, and a new file should be added. OSC seems a good way of getting information from Chuck to the script. There's a Perl library for running an OSC server, so it seems like this could well work. But before I go down this slightly Rube Goldberg route, I wanted to check: is this really the Best Way(TM)? Thanks, Stuart

1 0

sending an array from ChucK via OSC
by dparson 09 Mar '14

09 Mar '14

Does ChucK support sending an array as such? I am already using a loop to create a OSC foprmat string "iif[BUNCH OF fS]", so I suppose I can just forget the "[]" in the format string and send a bunch of scalar floats instead of an array. the array size is fixed. But, I thought I'd ask. I can't find any docs to suggest it, and I don't have time to dig into the implementation. I need to get ready for this: https://www.facebook.com/events/194651817409105/ Thanks. Dale (Acoustic Interloper) http://faculty.kutztown.edu/parson

1 0

platform-independent UIs
by David Loberg Code 07 Mar '14

07 Mar '14

I am a Mac-ANSI-American. I am now faced with the need to optimize (i.e., rewrite) some of my ChucK programs so that the user interfaces will work in other platforms (e.g., PC-ISO-Norwegian). Obviously, the ideal is to have a single version that will behave the same in any platform. Below are some of the things I have discovered in confronting OSX vs. Windows, ANSI vs. ISO, and USA keyboard layout vs. other languages. Please: a) correct me if there is something which I got wrong or misunderstood b) share with me any additional tips or advice for things I have overlooked KEYBOARD: Here is what I understand about HidMsg for keyboard devices. msg.which produces the machine key code (in decimal); msg.key produces the USB scan code, msg.ascii produces an ascii value (sort of) On Macs, msg.which and msg.key produce the same numbers. On PCs, they produce different numbers. Cross-platform, msg.which produces different numbers on Macs vs.PCs; msg.key produces the same numbers for both machines. Pressing 'a' on a Mac: msg.which == 4, msg.key == 4, msg.ascii == 65 Pressing 'a' on a PC: msg.which == 30, msg.key == 4, msg.ascii == 65 As such, a ChucK script using msg.which for key mapping is platform dependent. If you want it to be consistent always use msg.key instead. (Unless I am missing something, there doesn't seem to be a good reason for using msg.which for keyboard input) .ascii produces an ascii value (but not necessarily the same as the actual ascii character mapped to that key) a) for letters: the ascii number for the UPPER-case letter associated with that key for English layouts (even though it is actually the lower-case character which is getting pressed) b) for numbers/symbols: the ascii number for the lower-case character associated with that key for English layouts It doesn't seem to matter what keyboard language layout you specify for your laptop. That is, if you are using a German keyboard layout, you won't get ascii values for the uniquely German keys. However, it does seem to matter what kind of physical keyboard you are using. If it is an ANSI (American) keyboard, the .ascii results for are based on a standard US English keyboard layout. If it is an ISO (European) keyboard, the .ascii results are (sometimes) based on a British-PC English keyboard layout. In other words, unlike KBHit (which appears to give different ascii values for different upper and lower case characters), msg.ascii seems to use fixed tables for the ascii values. Since it doesn't give the true value of the character, it also doesn't seem like there is much point in writing programs which use msg.ascii for key mapping. The only advantages might be: a) if you already have the ascii values memorized or b) if you want quasi-random MIDI pitch generators that are already in a reasonable octave register (e.g., CliX). MOUSE/TRACKPAD: Cursor position: On a Windows PC, msg.cursorX and msg.cursorY (and the scaled versions) do not appear to work. Is there some other way of obtaining the absolute X-Y coordinates for the cursor? msg.deltaX and msg.deltaY work in both platforms, but appear to behave differently. if( msg.isMouseMotion ) { <<<msg.deltaX, msg.deltaY>>:} On a Mac, only one value will report at a time. When deltaX has a non-zero value, deltaY is always zero (and vice versa). Thus, at any given poll, you can determine movement East-West (deltaX) or North-South (deltaY) but not both. On a PC, it can report non-zero values for both coordinates at the same time. As such, it is possible to detect diagonal movement (i.e., NE, NW, SE, SW). This can be done on a Mac, but you must evaluate (deltaXnow && deltaYlast) || deltaXlast && deltaYnow) What else have I missed? thanks, david David Loberg Code School of Music Western Michigan University 1903 W Michigan Ave Kalamazoo, MI 49008-5434 code(a)wmich.edu

1 0