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

running() doesn't return status of the shred
by mario buoninfante 03 Jan '19

03 Jan '19

Hi, I found out that running() always return the value 0, doesn't matter if the shred is actually running or not. done() instead seems to work fine. I tried on my Linux machine running Ubuntu Studio 16.04 using ChucK 1.4.0.0. Here's a little script that shows the issue: 0 => int c; spork ~ loop() @=> Shred parallel; //---------MAIN--------- while( c < 5 ) { <<< "running(): " + parallel.running() + "\t||\t " + "done(): " + parallel.done() >>>; if( c == 2 ) { <<< "exiting the shred" >>>; parallel.exit(); } c++; 0.5::second => now; } //-------FUNCTIONS-------- function void loop() { while( true ) { 333::ms => now; } } Cheers, Mario -- Electronic Musician, Creative Coder, QA Engineer https://vimeo.com/creativecodingsalerno http://mbuoninfante.tumblr.com/ https://github.com/mariobuoninfante https://bitbucket.org/mariobuoninfante/

1 0

Newbie having audio issue
by Theo B. 02 Jan '19

02 Jan '19

Hi all, I'm new to Chuck and very excited about it. I've been trying to work in miniAudicle today, but have had an issue. When I try to use my AirPods, the VM crashes. Any advice? Happy New Year!Theo

1 0

SysExIn and SysExOut classes
by Mario Buoninfante 19 Dec '18

19 Dec '18

Hi, I made 2 simple classes that allow to send/receive SysEx messages on ChucK: https://bitbucket.org/mariobuoninfante/sysex/src/master/ All they do it's basically sending/receiving messages via OSC to/from Pure Data that deals with actual SysEx messages. It seems to work fine, but I didn't do any 'stress test'. Of course having to convert from/to OSC is a kind of a bottleneck, so I'd expect some 'performance issues' when dealing with big SysEx messages (ie firmware updates) , but I think it's fine for general purpose SysEx transmissions. I'd like to see, one day, these 2 classes (SysExIn and SysExOut) being part of the ChucK source code as members of the MIDI classes family. Let me know if you have any question. Cheers, Mario

1 0

Gen10 issue with coefficients
by mario buoninfante 08 Dec '18

08 Dec '18

Hi, I'm working with the Gen10 UGen and it seems like once I set up the coefficients, I can't change them on the fly anymore. To be more precise I can only add new sines to the table but I can't get rid of the ones that are already there. Here's an example where I try to remove the fundamental, but I can't Phasor phasor => Gen10 g10 => Gain volume => dac; volume.gain(0.1); g10.coefs([1.]); 0 => int c; while(true) { if(c==3) { g10.coefs([0., 0.,0.,0.,1.]); <<< "table update" >>>; } Math.random2f(500,700) => phasor.freq; c++; second => now; } When I update the table, instead of removing the 1st partial and add the 5th, I end up having both 1st and 5th. I had a quick look at the source code (ugen_osc.cpp, row 1469) and the possibility of having a coefficient equal to 0 is not considered. Would it be better if we could remove partials? Cheers, Mario -- Electronic Musician, Creative Coder, QA Engineer https://vimeo.com/creativecodingsalerno http://mbuoninfante.tumblr.com/ https://github.com/mariobuoninfante https://bitbucket.org/mariobuoninfante/

1 0

LAC 2019 : Call for Papers / Posters / Workshops/ Demos / Music / Multimedia Installations
by Romain Michon 05 Dec '18

05 Dec '18

Dear all, It is our pleasure to announce the 17th Linux Audio Conference (LAC-19). We look forward to see you at Stanford this Spring (see details below)! Cheers, [Apologies for cross posting, please circulate widely.] *17th Linux Audio Conference - CCRMA, Stanford University (USA), March 23-26, 2019* After seven years outside of the United States, Linux Audio Conference (LAC) <https://lac.linuxaudio.org/> is coming back to Stanford University <http://stanford.edu/> on March 23-26, 2019 for its 17th edition! LAC is the international conference about Free/Open-Source Software for music, sound, and other media with GNU/Linux as the main platform. More information about this event can be found on the conference website: https://lac.linuxaudio.org/2019/ *Call for Papers / Posters / Workshops* LAC 2019 invites submissions of papers, posters, and workshops addressing all areas of audio processing based on Linux and open source software. All submissions and presentations are in English. Submitted papers are expected to respect academic standards and must be complete (*a simple abstract is not enough*). Submissions can focus on technical, artistic, and/or scientific issues and can target developers and/or users. This includes (but is not limited to) the following categories: - Audio and Music Languages - Audio Hardware Support - Audio Plugins - Drivers, System and Sound Architecture - Education and E-Learning - Games - Interactive Art - Interface Design - Live Coding - Live Performance - Media Art - MIDI, OSC... - Mobile Audio - Music Composition - Music Production - Networked Audio - Physical Computing - Projects Realized using Linux Audio - Realtime Kernel and Linux Distributions - Signal Processing and Sound Synthesis - Sound Spatialization - Standards and Protocols - Video - Etc. *Full Papers* Full papers must be written and presented in English. The length of papers is 4 to 8 pages, with up to 5 keywords, including an abstract of up to 200 words. The abstract will be published on the conference website once the paper has been accepted. The full paper will be available on the website during and after the conference. All papers are peer reviewed by a committee of experts from different disciplines. Reviewers may suggest improvements to the author(s), or require changes in order to accept the submission. The duration of the presentation is 25 minute followed by a 5 minute discussion. *Poster Papers* Poster papers must be written in English, should be 2-4 pages, with up to 5 keywords, including an abstract of up to 150 words. The abstract will be published on the conference website once the poster has been accepted. All posters are peer reviewed by a committee of experts in different disciplines. Reviewers may suggest improvements to the author(s), or require changes in order for the poster to be accepted. *Demos* Demos are informal project (e.g., plug-in, software, interface, idea, etc.) presentations that will be carried out in parallel with poster presentations. Demos can be submitted through this online form <https://lac.linuxaudio.org/2019/submissions.html> to be added to the conference program. *Workshops* Workshop presentations (max duration of 2h) should be 1-4 pages, with up to 5 keywords, including an abstract of up to 150 words to be published on the conference website. Make sure that your proposal indicates if participants are expected to have a specific level, if there are prerequisites, if you'd like to limit the number of participants, etc. Workshops will take place in the CCRMA classroom (which can host approximately 30 people). A projector and a 4 channels sound system will be available in this space. Submit a brief description of the workshop including a URL (if available). *How to Submit Papers / Posters / Workshops?* - Use the online submission tool <http://submissions.html/> - Choose the relevant submission type (paper, poster, or workshop) in addition to your 5 categories - The required file format is PDF. Authors must use the provided templates <https://lac.linuxaudio.org/2019/doc/LAC-19-templates.zip> for paper formatting. - Please let us know if you need a special technical setup for your presentation. *Call for Music / Multimedia Installations* LAC 2019 also invites submissions of musical works involving the use of technology/open source software and multimedia installations. A jury will select the compositions and installations to be included in the conference program according to artistic merit and technical feasibility. Please be prepared to perform your work yourself and make sure that you have all resources needed to perform your piece (e.g., instruments, props, other performers, etc.). LAC 2019 cannot pay for any expenses related to a performance (e.g., performers, travel, accommodation, special equipment, etc.). SCLOrk <https://www.scu.edu/cas/music/ensembles/sclork/> will be available to perform new (or old) laptop orchestra compositions, so this type of submission is encouraged this year! SCLOrk <https://www.scu.edu/cas/music/ensembles/sclork/> is the Santa Clara Laptop Orchestra and uses exclusively Linux computers. Musical works and installations can address all areas of digital audio and audiovisual art. This includes (but is not limited to) the following categories: - Electronic Music - Electroacoustic Music - Mixed Music - Acoustic Music - Sound Installation - Interactive Art - Audiovisual Installation - Game in art - Web and Connected Art *Available Setups* For concerts, LAC will provide the following equipment: - CCRMA Stage: 56.8 full 3d sound system (up to 6th order Ambisonics) - CCRMA Listening Room: 22.4 sound system (up to 3d order Ambisonics) - SCLOrk <https://www.scu.edu/cas/music/ensembles/sclork/> (the Santa Clara Laptop Orchestra). Pieces accepted for a performance with SCLOrk will be added to the rehearsal schedule of the corresponding SCU <https://www.scu.edu/> class. - Additional requests can be made but are not be guaranteed. *How to Submit Music / Multimedia Installations?* - Use the online submission tool <https://lac.linuxaudio.org/2019/submissions.html> - Select the submission type (performance) - The required file format is PDF, formatted for Letter paper size. Submissions should include: - Description of the project program notes - Link to video or audio demonstration of the project - Technical rider of the work *Important Dates* - *Submission Deadline:* December 7, 2018 (11:59pm PST) - *Notification of Acceptance:* January 18, 2019 - *Camera-ready Version Due:* February 15, 2019 - *Conference Dates:* March 23-26, 2019 *Contact* - lac(a)linuxaudio.org Additional information about LAC-19 can be found on the conference website: https://lac.linuxaudio.org/2019/

1 2

Is the sample rate available in ChucK code?
by Forrest Cahoon 05 Dec '18

05 Dec '18

I've found that I can compute the sample rate as a float inside of chuck code by using 1::second/1::samp but I'm wondering if it might be available in some other way, like a global variable. I was thinking, if something doesn't already exist, maybe it could be a variable belonging to the Machine class library. It is a property of the Virtual Machine, right?

1 0

TCP protocol
by Mario Buoninfante 04 Dec '18

04 Dec '18

Hi, Does anyone know if it's possible to use TCP instead of UDP in ChucK? Cheers, Mario

7 11

Re: [chuck-users] TCP protocol
by mario.buoninfante 04 Dec '18

04 Dec '18

Hi Jose, Yes, that's a solution, you're right. But I was trying to do everything in ChucK, also to avoid further bottlenecks due to conversions from UDP to TCP. But I'll consider this option in case I can't find better solutions. Cheers, Mario Sent from my Wiko ROBBYOn Dec 3, 2018 17:33, José de Abreu <abreubacelar(a)gmail.com> wrote: > > Just an idea, i know that you patch in puredata too Mario. How about making chuck send udp to puredata and making puredata send tcp from there? actually puredata could be any other software, just to make the bridge > > Em Seg, 3 de dez de 2018 13:24, Mario Buoninfante <mario.buoninfante(a)gmail.com escreveu: >> >> Hi Jordan, >> >> Thanks for your reply. >> I got your points and I think you're right about the different design goals. In my case I simply need to talk with a piece of HW that 'speaks' TCP. But the 'netcat' solution doesn't seem to be the best one, for all the reasons you mentioned. Probably it's still the right direction, but it needs to be refined for sure. >> If I simple open a port using Std.system(), without immediately closing it, that'll take over the shell and my ChucK script won't proceed (the shell waits for some input). >> The idea of having 2 shells opened, and make 2 different scripts talking to each other, could be a solution and I want to give it a try. That said, having to convert from OSC/UDP, to TCP could further affect the performances. Anyway, I'll have a look and share with the mailing list in case I end up with something useful. >> >> Cheers, >> Mario >> >> On Sun, 2 Dec 2018 at 20:47, Jordan Orelli <jordanorelli(a)gmail.com> wrote: >>> >>> I'm like ... 80% sure that there's no TCP-handling facilities built in, but I may be wrong here. If there is, I surely don't know about it. >>> >>> Can you tell us a little more about your use case? >>> >>> The design goals of TCP and ChucK are very different with respect to time. ChucK is designed around guarantees about time and timeliness. TCP is not designed around timeliness or latency in general: TCP is designed around guarantees about ordering (messages always appear in order) and delivery (messages are guaranteed to be delivered). Since every byte sent over a TCP socket has to be eventually acknowledged, and all bytes have to be processed in order, a stall in the network (a normal occurrence) could mean later messages being delayed, much like a traffic jam. It's not possible to have timing guarantees with TCP. >>> >>> I'm not sure how to find it in the source code, but maybe someone else here knows: does calling Std.system create a new shell process for each invocation? That would be a fairly inefficient way to go about things. Also since you're piping to another process, that's a new netcat process for each invocation (so it's either one or two processes per invocation), and a new TCP socket for every invocation. TCP is especially slow at the very beginning of communication. >>> >>> If I were in your shoes, I would probably write a separate program that acts as a server and serves an OSC-based protocol. This server would take your messages as OSC and translate them and then forward them to the intended recipient over just one TCP connection and continue to use that one connection the whole time. It may or may not respond to your ChucK program over OSC, depending on whether you want the ChucK program to get responses to its requests (probably not?). >>> >>> >>> On Sat, Dec 1, 2018 at 1:25 PM mario buoninfante <mario.buoninfante(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> >>>> It seems like accessing the shell and use "netcat" (on Unix) is a possible solution. Quite an exotic workaround but better than nothing I'd say. >>>> >>>> Something like that seems to work: >>>> >>>> // run ChucK with "--caution-to-the-wind" >>>> >>>> "echo -ne '" => string prefix; >>>> "' | netcat 127.0.0.1 3333 " => string suffix; // netcat <target ip> <target port> >>>> >>>> while(true) >>>> { >>>> Math.random2(0,127) => int r; >>>> prefix + Std.itoa(r) + suffix => string msg; >>>> Std.system(msg); >>>> >>>> second => now; >>>> } >>>> >>>> >>>> Please, let me know if anyone has a better solution. >>>> >>>> >>>> Cheers, >>>> >>>> Mario >>>> >>>> On 01/12/2018 18:04, mario buoninfante wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> I also tried opening a file in /dev/tcp/<target ip>/<target port>, but it didn't work. I'm on Ubuntu 16.04. Any idea? >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Mario >>>>> >>>>> >>>>> On 30/11/2018 16:52, Mario Buoninfante wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Does anyone know if it's possible to use TCP instead of UDP in ChucK? >>>>>> >>>>>> Cheers, >>>>>> Mario >>>>> >>>>> >>>> -- >>>> >>>> Electronic Musician, Creative Coder, QA Engineer >>>> >>>> https://vimeo.com/creativecodingsalerno >>>> >>>> http://mbuoninfante.tumblr.com/ >>>> >>>> https://github.com/mariobuoninfante >>>> >>>> https://bitbucket.org/mariobuoninfante/ >>>> >>>> _______________________________________________ >>>> chuck-users mailing list >>>> chuck-users(a)lists.cs.princeton.edu >>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>> >>> _______________________________________________ >>> chuck-users mailing list >>> chuck-users(a)lists.cs.princeton.edu >>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >> >> _______________________________________________ >> chuck-users mailing list >> chuck-users(a)lists.cs.princeton.edu >> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

2 1

Has anyone written some additive synthesis ChucK code they might share?
by Forrest Cahoon 02 Dec '18

02 Dec '18

I'm about to start writing a base class for additive synthesis in chuck, with overrideable methods to calculate sample-specific harmonic frequency, harmonic amplitude, and number of harmonics. I would then spork all the harmonics with each knowing its own harmonic number and each would go into a per-sample loop adjusting frequency and amplitude by calling these overrided methods at each step. I'm wondering if anyone else has approached additive synthesis and if so, if you used a different technique, and especially if you'd be willing to share your code. Forrest

1 0

Chunity - RunCode() vs RunFile() affecting the stereo image
by Luis Bergmann 27 Nov '18

27 Nov '18

Hello all, I've been making a demo using Chunity to create music and sound for the Unity demo Space Shooter. I think Chunity is great and open up lots of possibilities, not only regarding procedural synthesis but also implementing features commonly found in game audio middlewares like Fmod and Wwise. One particularly odd issue that I've found is that when using RunFile the audio plays in mono only. That doesn't happen when using RunCode() or with Machine.add(), as the stereo image using Pan2 or SndBuf2 is not affected using these methods. Does anyone notice that, or maybe I am missing something? Best regards, Luis -- Luis Bergmann | +55 11 94284 0574 Twitter: @_luisbergmann

2 2