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

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

Biweekly appointment with ChucK on the Facebook group
by mario buoninfante 07 Nov '18

07 Nov '18

Hi everybody, Sorry in advance for the spam, I simply wanted to let you guys know that we're organizing a biweekly appointment with ChucK on the Facebook group. It's just an occasion to share works made with ChucK, focusing on sound and music, without getting lost in technicalities. The idea is to "force" us to do something creative, artistic, without worrying too much about the way the goal has been accomplished. If you feel like you want to take part, please give us a shout: https://www.facebook.com/groups/1593843507578422/ Happy ChucKing, Mario -- Electronic Musician, Creative Coder, QA Engineer https://vimeo.com/creativecodingsalerno http://mbuoninfante.tumblr.com/ https://github.com/mariobuoninfante https://bitbucket.org/mariobuoninfante/

7 8

ChucK scripting language for Audio/MIDI testing
by mario buoninfante 05 Nov '18

05 Nov '18

Hi, Has anyone ever used ChucK for audio/MIDI testing? I personally used it in more than a couple of occasions, and I found it really useful. Nowadays, also for audio and MIDI, Python is pretty much the standard language for testing. Actually it is quite powerful, especially considering the number of libraries available, but despite its versatility and easy of use, I found it a bit annoying for audio/MIDI testing. It seems to me that languages like ChucK and Pure Data are better candidates for this kind of job. I've been using Pd for testing for almost 2 years now (from regression to semi-automated tests), and I'm really happy with it. No need to configure anything more than the essential, pretty stable and reliable, multi-platform, etc. Then, recently I started doing the same with ChucK, that of course has some advantages being a "text-based" language rather than a graphical one. In the specific I've been using it to talk with a CLI via Serial (hardware testing). Perfect, stable, reliable, the possibility to easily manage events... in short, brilliant! I think it would be perfect for test automation as well! The only missing thing is a full MIDI implementation (I know, I said that something like 5 billions times here on the mailing list, and I'm sorry I'm being "a bit" boring). But, SysEx messages are crucial nowadays. A lot of gears use it for basically everything from data transmission (patches, bootloader/firmware updates, etc.) to parameters control (from DX7 till the most recent Korg Volca series), plus internal functionalities. I think this is the real bottleneck at the moment, and I hope one day it will get "fixed". Anyway, I'm saying this for 2 reasons. First, I'd like to get some feedback from you guys and see if anyone else has been doing similar things. Second, I think start using ChucK for audio/MIDI testing could be really good for ChucK itself and its community. I don't know, maybe that's just me thinking about stupid things, but I suppose if people (and when I say people I also mean companies) start using ChucK for work reason, the amount of support increases as well. There will be more users for sure, that means more beta testing, and probably more support in developing it as well. 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

data sonification with Chuck?
by Panos Amelidis 25 Oct '18

25 Oct '18

Hello All I want to explore data sonification in the context of making music pieces and/or sound installations. At the moment I am going through reading the Sonification Handbook and find it quite fascinating. I have no experience whatsoever on DS and to be honest I find it to be quite a difficult task. But, I am... determined to get a result… If any of you would like to share some thoughts, directions or examples that would be much appreciated. I have some experience with Chuck but I used to work a lot with MaxMSP (and some supercollider experience as well, mainly using it for audio files manipulation). I am willing to improve my competence in Chuck though. Thank you all in advance for the help! best ~panos

1 0

SinOsc UGen
by mario buoninfante 24 Oct '18

24 Oct '18

Hi, I ran the same simple test on my Linux machine (Asus i5-6198DU 2.30 GHz, 8 Gb RAM - Ubuntu Studio 16.04) and here I've got different results: SndBuf x 50 - 15.3% CPU usage SinOsc x 50 - 15.7% CPU usage What could explain this? cheers, Mario

1 0

Chunity v1.0.1 released + VSCode Syntax Highlighting Plugin!
by Jack Atherton 24 Oct '18

24 Oct '18

Dear all, Chunity version 1.0.1 is now up on the Unity Asset Store. This version contains internal bugfixes and also implements a retry system if you get your requests for global variables slightly out of order. http://u3d.as/1bvM or download the unitypackage directly from http://chuck.stanford.edu/chunity/files/Chunity_v101.unitypackage Also, I'm happy to announce that there is now a Chunity plugin for VSCode! You can install this to modify the definition of the C# language in VSCode to do embedded ChucK syntax highlighting every time you use the Chunity function RunCode(). Example: https://i.imgur.com/GdBilc1.png https://marketplace.visualstudio.com/items?itemName=jatherton.chunity Many thanks to Forrest Cahoon, who wrote the original ChucK VSCode plugin, which is a dependency for the Chunity plugin. https://marketplace.visualstudio.com/items?itemName=forrcaho.chuck As always, happy ChucKing!! Best, Jack + the ChucK team Music:Computing:Design @ CCRMA

2 1

SinOsc UGen
by Mario Buoninfante 24 Oct '18

24 Oct '18

Hi, I tried using SndBuf instead of SinOsc (both on Rasp Pi and a MacBookPro), but SinOsc seems to offer better performances. On the Mac (2.7 GHz Intel Core i5, 16 GB 1867 MHz DDR3, MacOS Sierra 10.12.6), running the code you'll find below, I've got this CPU usage (I used top from terminal to check the CPU usage): SndBuf x 50 - CPU usage 24.0% SinOsc x 50 - CPU usage 16.4% the same seems to happen on Rasp Pi 3, despite I had to use 25 oscillators to avoid glitches. here's my code ------------SinOsc Version------------ SinOsc s[50]; for(0 => int c; c<s.size(); c++) { s[c].gain( (1/( s.size()) $ float) * 0.25); s[c] => dac; } while(true) { for(0=>int c; c<s.size(); c++) { Math.random2f(300, 500) => s[c].freq; } 200::ms => now; } ------------SndBuf Version------------ SndBuf s[50]; for(0 => int c; c<s.size(); c++) { s[c].read(me.dir() + "/sine_1024.wav"); s[c].pos(0); s[c].loop(1); s[c].gain( (1/( s.size()) $ float) * 0.25); s[c] => dac; } while(true) { for(0=>int c; c<s.size(); c++) { Math.random2f(300, 500) => s[c].freq; } 200::ms => now; } ------------------- cheers, Mario

1 0

SinOsc UGen
by Mario Buoninfante 24 Oct '18

24 Oct '18

Hi, As already pointed out by someone else here, I noticed we've got the SinOsc UGen that doesn't use a wavetable but instead uses the sin function. I don't know what the reason behind this decision, but I was wondering whether it would be possible to also have a variant that uses wavetable as well. I presume that would help a bit in terms of performances, and I think it would be useful in scenarios where ChucK runs on platforms like Raspberry Pi. cheers, Mario

2 2