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

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

Workshop on Audio Plug-Ins Design in Faust
by Romain Michon 19 Feb '14

19 Feb '14

Hi Folks, I'll be giving a workshop on Audio Plug-Ins Design in Faust this summer at the Center for Computer Research in Music and Acoustics (Stanford University, USA) this summer (Mon, 07/07/2014 - Fri, 07/11/2014). Thanks to Spencer Salazar, Faust can be used to easily create chugins so I thought that this event might interest some of the members of this list. More informations are available on this page: https://ccrma.stanford.edu/workshops/faust-workshop-2014 You can also contact me directly if you have specific questions: rmichon(a)ccrma.stanford.edu Cheers, -- Romain Michon PhD Candidate Center for Computer Research in Music and Acoustics Stanford Universityhttp://ccrma.stanford.edu/~rmichon

1 0

Using Chuck as an embedded language
by Phenix Nunlee 13 Feb '14

13 Feb '14

I am interested in using chuck as an embedded language? I want to try to model circuit with transfer functions.

1 0

Re: [chuck-users] Command line arguments
by Stuart McDonald 12 Feb '14

12 Feb '14

Bah, I just noticed me.arg(0) in http://chuck.cs.princeton.edu/doc/examples/basic/rec.ck Nothing to see here, etc. Stuart

1 0

Command line arguments
by Stuart McDonald 12 Feb '14

12 Feb '14

I am entertaining an aspiration to send an arbitrary list of wav files to chuck to process, so that a user could drag and drop files into a directory, and wrap a call to chuck in a script that takes the result of ls and passes the files to chuck as command line arguments. The closest I've found on Google is this post: https://lists.cs.princeton.edu/pipermail/chuck-users/2011-January/005932.ht… much changed since then? It's not essential as I could contrive the calling script to compile a .ck file containing the wav files ahead of time and pass that to chuck, but I figured I'd check in case there are more seemly options. Thanks Stuart

1 0

Re: [chuck-users] machine.add issues (Amy Crawford)
by Perry R Cook 11 Feb '14

11 Feb '14

Amy, Judging from the C: in your post, I gather you are using Windows? If so, we had a bug with ChucK wherein it was interpreting the colon as the usual marker for arguments to a program. So it was interpreting that path as a ChucK file named "C" with an argument of all the path after the colon. Spencer made a patch for that and released it as an update. Now ChucK ignores a colon so early (meaning that we can't have single letter ChucK files, but that would be pretty goofy anyway). Make sure you have the newest version of ChucK from the download site: http://chuck.stanford.edu/release/files/exe/chuck-1.3.3.0.msi You may have to remove previous versions to do a clean install. Spencer?? PRC 1. new to chuck having machine.add issues (Amy Crawford) 2. Re: new to chuck having machine.add issues (Michael Heuer) 3. Re: new to chuck having machine.add issues (Mois?s Gabriel Cachay Tello)

1 0