Sorry for the title. I'm currently writing a type system in ChucK and have defined a supertype with types extending it. It appears as if I cannot just cast an instance of the supertype into the more specific type and use its members instead of the more generic ones.

// String.ck
public class String
{
    string value;

    fun static String create(string value)
    {
        String s;
        value => s.value;
        return s;
    }
}

// Type.ck
public class Type
{
    string type;
    Object storage;
}

// StringType.ck
public class StringType extends Type
{
    "string" => type;

    fun string value()
    {
        return (storage$String).value;
    }
}

// example.ck
new Type @=> Type t;
"string" => t.type;
String.create("example") @=> t.storage;

<<< (t$StringType).value() >>>;

$ chuck String.ck Type.ck StringType.ck example.ck
chuck: chuck_instr.cpp:4774: virtual void Chuck_Instr_Dot_Member_Func::execute(Chuck_VM*, Chuck_VM_Shred*): Assertion `m_offset < obj->vtable->funcs.size()' failed.

What's notable is that if you add Type.value(), it is used in that case instead.

There doesn't appear to be a way to make use of StringType.value() other than writing a static method doing the same kind of access or creating a StringType object, writing the data into it and invoking its member.

I'm on Arch Linux, ChucK 1.3.5.2.

With a git clone of LiCK and

$ chuck --version

chuck version: 1.3.3.0 (chimera)
   mac os x : intel : 64-bit
   http://chuck.cs.princeton.edu/
   http://chuck.stanford.edu/

$ chuck --loop
[chuck](VM): sporking incoming shred: 1 (import.ck)...
...
[chuck](VM): sporking incoming shred: 288 (RubberBand.ck)...
"LiCK imported." : (string)
[chuck](VM): sporking incoming shred: 1 (syTuningsExample.ck)...
initializer... 0x105ff3b10 0x105b608c0 0x105b56ed0 
Segmentation fault: 11

in one terminal and

$ chuck + import.ck 
$ chuck + examples/syTuningsExample.ck

in another I get a seg fault.

The offending line in syTuningsExample.ck appears to be

tuning @=> _t[s][a];

https://github.com/heuermh/lick/blob/master/examples/syTuningsExample.ck

The code here is not so nice because I'm trying hard to work around not having static arrays of object references.

The documentation says that SinOsc.sync(0) syncs the frequency to input. This works with oscillators as input, but not Envelope.

Envelope e => SinOsc s => dac;
220 => e.value;
440 => e.target;
minute => e.duration;
minute => now;

But s's frequency remains at zero.

Using an envelope as freq input would greatly simplify glissando.

It is possible to read 8-/16-bit ints from a file, but not to write them.

The following code causes ChucK to crash during compilation:

[[53,57,60,63],[57,60,63,69]] @=> int chordz[][];
54 => chordz[0,0];

The issue seems to be the comma in the array subscript, which is not valid syntax, but should generate a compile error rather than crashing.

See this thread:
https://lists.cs.princeton.edu/pipermail/chuck-users/2014-August/007708.html

The following code causes ChucK to crash:

null @=> string str;

<<< str >>>;

As soon as I stop and restart the Virtual Machine it will not receive data any more. I have to restart miniAudicle to make it work again. It doesn't happen in Terminal. (Mac)

Hi Spencer, 😎

I may not know what I'm doing, but I think (1) the Delay ugens implemented from STK have a .clear() method, and (2) that's not pulled through to ChucK. That is, I'd like to do something like delay.clear(); to my object delay of type DelayA, but that doesn't work. Is there an easy fix or hack for this? Maybe I'm a total n00b?

Thanks!
Tim

Export (to .wav file) doesn't work. In console monitor I get this error when I try:
[export.ck]: no such file or directory

I've build simple looper on Raspberry Pi → https://github.com/szymonkaliski/LoopPI — I'm using latest archlinux, jack, and chuck. My looper code is here: https://github.com/szymonkaliski/LoopPI/blob/master/Looper/looper-class.ck

Unfortunately I have very hard to debug / catch problem — after some time (differs every time I test it, sometimes 5 minutes, sometimes 3 hours) new recordings produce crackling sound, what is strange if I have 4 loops, three of them are playing (looping) fine, just when I'm recording to fourth one after some time it begins to crackle. I couldn't find correlation between this and any jack/chuck settings (I've played with buffer sizes, niceness, jack priorities, etc). I also couldn't find any correlation with system settings (swap on/off, with and without overclocking), or the app itself (two or four loops — it seems not to be happening with one loop, or maybe I was just lucky / didn't wait long enough)... I even installed fresh system on new SD card and set it up from grounds up, it didn't help. I'm completely lost.

I'm almost 100% sure it's something with chuck, because if the jackd/linux/hardware was a problem then all loops would start to crackle, but they don't, just the "new" one.

Any help / pointers / direction would be greatly appreciated. I slowly start to think that I should just give up and try re-writing this in some other language, that would be a shame though, as ChucK is fun to play with :)

I found a reference to an issue where a "memory exhausted" error occurs when larges files are parsed with Chuck. I'm having that problem! :) The post:

https://lists.cs.princeton.edu/pipermail/chuck-users/2009-April/004029.html

In that message Tom says that one would need to rewrite the grammar of the YACC file. I'd like to attempt this and I have a branch here with questions:

https://github.com/stuntgoat/chuck/pull/1/files

The following program appears to crash on Linux if no supported HID device is available. The crash occurs on VM shutdown.

Hid kb;
kb.openKeyboard(0);

fun void kbListen()
{
    kb => now;
}

30::second => now;

In ChucK, all the timing is relative to the time the process started. This makes it hard to track down latency problems when communicating with other programs, as is motivated by this thread in the mailing list: https://lists.cs.princeton.edu/pipermail/chuck-users/2016-May/008065.html

So here is the feature request:

• Add native support to work with the system time (just printing it would be a great start)

The following line of code reproduces the issue:

<<< 2 / 0 >>>;

miniAudicle: 1.3.5.2 (the About dialog says: 1.3.5.2-beta-3 (chimera) 32-bit).
OS: Windows 10 Pro, 64-bit.

When running the HID example joy.ck (http://chuck.cs.princeton.edu/doc/examples/hid/joy.ck) after building from source or downloading chimera, this error message appears: https://gist.github.com/ffdd/5136699e3efba96d6cb5

Any ideas?

class Crash extends Chugen {
  fun float tick(float v) {
    return v;
  }
}

SinOsc s => Crash c => dac;
440.0 => s.freq;
1::second => now;

Crashes in Chuck_VM_Shred::run due to vm_ref being 0x0. Replacing vm_ref with vm fixes the crash, but it's unclear to me if that's a correct thing to do.

"\"\"" => string x;
<<< x >>>;
<<< RegEx.replaceAll("\"", "\\\"", x) >>>;
// expected it to print "\"\"", got "\""" instead

"\"f\"" => string y;
<<< y >>>;
<<< RegEx.replaceAll("\"", "\\\"", y) >>>;
// this on the other hand prints "\"f\"" as expected

I ended up writing my own replacement function that operates on plain strings.

Compare with Ruby:

>> puts "\"\"".gsub(/\"/, "\\\"")
\"\"
=> nil

<<< RegEx.replace(".*", "...", "foo\nbar") >>>;

Expected output: "...\nbar"

Actual output: "..."

To rectify this, one needs to rewrite the pattern as "[^\n]*".

Originally reported to chuck-users@ mailing list, see thread: 147th shred removed...segmentation fault?

shred.ck:

fun void blink()
{
  while (true)
  {
    50::ms => now;
  }
}

Shred shred;
spork ~ blink() @=> shred;

0 => int count;

while (true)
{
  200::ms => now;
  shred.id() => Machine.remove;
  spork ~ blink() @=> shred;
  <<<"count", count++>>>;
}

ChucK version 1.3.4.0 on OSX

$ chuck --silent shred.ck
...
[chuck](VM): removing shred: 145 (spork~exp)...
count 143
[chuck](VM): removing shred: 146 (spork~exp)...
Segmentation fault: 11

ChucK version 1.3.4.0 on 64-bit linux alsa

$ chuck --silent shred.ck
...
[chuck](VM): removing shred: 22 (spork~exp)...
count 20
[chuck](VM): removing shred: 23 (spork~exp)...*** buffer overflow
detected ***: ./chuck terminated

Linux version 3.16.0-4-amd64
Debian GNU/Linux stretch
gcc version 4.8.4

`me.dir() => string root;

<<< root >>>;

Machine.add(root + "Utils.ck");
Machine.add(root + "Sampler.ck");
Machine.add(root + "BPM.ck");
Machine.add(root + "Mixer.ck");`

When I add to vm chuck program with miniAudicle <<< root >>>; print to console right path, but if I trying to start chuck with 'chuck --loop' from my home directory and then adding script with 'chuck + myProgramm.ck' i have got an error:

chuck: sporking incoming shred: 1 (import.ck)...
"" : (string)
[Utils.ck]: no such file or directory
[Sampler.ck]: no such file or directory
[BPM.ck]: no such file or directory
[Mixer.ck]: no such file or directory

if I start chuck from same directory with myProgramm.ck <<< root >>> print correct path.

I encountered a strange case where a variable was changing value within the scope of an if statement, because I had a superclass with an identical variable name. I am able to reproduce it with this simple case:

class A 
{
    10000 => int foo;
}

class B extends A 
{
    fun void bar()
    {
        0 => int foo;

        <<< "a", foo >>>;
        {
            <<< "b", foo >>>;
        }
        <<< "c", foo >>>;
    }
}

Prints out:

a 0 
b 10000 
c 0 

(see https://lists.cs.princeton.edu/pipermail/chuck-users/2014-August/007688.html)

RtAudio now supports WSAPI on Windows, which is supposed to be better than DirectSound. Update chuck to experimentally use this (and consider making it default in future).

The ChucK build on OSX 10.9.x links to libstdc++, which is ok for using ChucK standalone but breaks when trying to use ChucK with libraries linked against libc++ (e.g. LADSPA plugins).

This works for me but of course won't build on earlier OSX versions

$ git diff .
diff --git a/src/makefile.osx b/src/makefile.osx
index 4531ee1..47c7c30 100644
--- a/src/makefile.osx
+++ b/src/makefile.osx
@@ -23,13 +23,13 @@ CFLAGSDEPEND+= -D__MACOSX_CORE__ $(FORCE_M32) $(ISYSROOT)

 FRAMEWORKS+= CoreAudio CoreMIDI CoreFoundation IOKit Carbon AppKit Foundation
 LDFLAGS+= $(FORCE_M32) $(ISYSROOT) $(addprefix -framework ,$(FRAMEWORKS)) \
-    $(LINK_EXTRAS) -lstdc++ -lm
+    $(LINK_EXTRAS) -lc++ -lm

 CSRCS+= util_sndfile.c


 # this is to link properly on leopard...
-MACOSX_DEPLOYMENT_TARGET=10.5
+MACOSX_DEPLOYMENT_TARGET=10.9
 export MACOSX_DEPLOYMENT_TARGET
 # option 2, add this to the gcc flags: -mmacosx-version-min=10.4

I'm trying to write a ChucK shred that detects when all but two (itself and a rec.ck) shreds have finished in the VM. I realise the Machine.status method prints the status of the VM, but it returns an integer (I keep getting -16), and I can't quite figure out what the integer represents. I haven't found any documentation on what the return value of this function represents, and I've looked through the source code, but I haven't quite understood how calls to the standard libraries are handled in the VM.

Is it currently possible to determine how many shreds are running in the VM from code? If not, would you be open to a PR for this functionality in the Machine lib?

When I click the "Start Virtual Machine" button in the Virtual Machine window, in miniAudicle, the button changes its text to "Stop Virtual Machine" and becomes disabled (grayed out). So, there's no way to stop the virtual machine without restarting miniAudicle.

miniAudicle: 1.3.5.2 (the About dialog says: 1.3.5.2-beta-3 (chimera) 32-bit).
OS: Windows 10 Pro, 64-bit.

(Windows)

I don't know if this is a bug or just a lack of understanding on my part, but I was experimenting with the 'dyno' UGEN and saw some results which don't make sense to me. I ran the code below from miniAudicle:

adc => Gain g => Dyno dyno => dac;
dyno.limit();
5::ms => dyno.attackTime;
300::ms => dyno.releaseTime;
<<< "slopeAbove =", dyno.slopeAbove() >>>;
<<< "slopeBelow =", dyno.slopeBelow() >>>;
<<< "thresh =", dyno.thresh() >>>;
<<< "attackTime =", dyno.attackTime() >>>;
<<< "releaseTime =", dyno.releaseTime() >>>;
<<< "externalSideInput =", dyno.externalSideInput() >>>;

And this was displayed in the console:

slopeAbove = 0.100000
slopeBelow = 1.000000
thresh = 0.500000
attackTime = 13230.000000
releaseTime = 13230.000000
externalSideInput = 0

After scratching my head a bit, I figured out that the attackTime and releaseTime are printed as number of samples (assuming a 44100 sample rate), but shouldn't the attackTime be 220.5 (possibly rounded or truncated to an integer)?

I'm running version 1.3.5.0-beta-7 (Windows 32-bit), which I believe is the latest version for Windows. Also, in general, I've noticed that the default values for UGEN's aren't always as stated in the documentation.

Thanks.

Ability to open arbitrary file paths with SerialIO, for advanced usage and serial devices that for whatever reason don't show up in the serial device list.

I.e. ADSR.RELEASE, ADSR.ATTACK, ADSR.DONE, etc.

Needed for consistency with Digital Artists book

chuck examples/event/kb.ck runs as expected and prints the events. chuck --silent examples/event/kb.ck does the same, but at full CPU usage. This is somewhat annoying as I'm using the --silent to disable rtaudio errors for a script not doing any audio processing.

I'm on Arch Linux, using the 1.3.5.2 snapshot.

This charming snippet of malformed code will crash ChucK 1.3.5.0 (and miniAudicle with it):

SinOsc s => dac;
[s] => SinOsc a[];

$ chuck --probe
[chuck]: found 5 device(s) ...
[chuck]: ------( audio device: 1 )---------------
[chuck]: device name = "Apple Inc.: Built-in Microphone"
[chuck]: probe [success] ...
[chuck]: # output channels = 0
[chuck]: # input channels  = 2
[chuck]: # duplex Channels = 0
[chuck]: default output = NO
[chuck]: default input = YES
[chuck]: natively supported data formats:
[chuck]:   32-bit float
[chuck]: supported sample rates:
[chuck]:   32000 Hz
[chuck]:   44100 Hz
[chuck]:   48000 Hz
[chuck]:   88200 Hz
[chuck]:   96000 Hz
[chuck]: 
[chuck]: ------( audio device: 2 )---------------
[chuck]: device name = "Apple Inc.: Built-in Output"
[chuck]: probe [success] ...
[chuck]: # output channels = 2
[chuck]: # input channels  = 0
[chuck]: # duplex Channels = 0
[chuck]: default output = YES
[chuck]: default input = NO
[chuck]: natively supported data formats:
[chuck]:   32-bit float
[chuck]: supported sample rates:
[chuck]:   44100 Hz
[chuck]:   48000 Hz
[chuck]:   88200 Hz
[chuck]:   96000 Hz
[chuck]: 
[chuck]: ------( audio device: 3 )---------------
Segmentation fault: 11

On this machine I have Apogee ONE and Soundflower drivers and the ONE device is not currently connected. If I remember right with previous ChucK versions the ONE comes up as device 3, sorry will require more investigation on my part.

$ uname -a
Darwin foo.local 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64

$ chuck --version

chuck version: 1.3.4.0 (chimera)
   mac os x : intel : 64-bit
   http://chuck.cs.princeton.edu/
   http://chuck.stanford.edu/

From https://lists.cs.princeton.edu/pipermail/chuck-users/2014-May/007607.html

I was looking at the new Osc support classes. When using OscIn, I can't
seem to receive more than the first character of a string.
If I replace the OscIn code with the equivalent using OscRecv code then the
strings come through okay.
If I sent the equivalent data to a separate program - e.g. PD - then the
strings also come through okay.
Conversely, if I send strings from PD to ChucK then, once again, my OscIn
code only picks up the first character.
So, I am assuming the issue lies with my code for OscIn rather than OscOut.
If anyone could put their finger on the problem, I would be most grateful.

And a separate issue with .addAddress: "oIn.addAddress( "/chuck/data,
ifss" )" works but "oIn.addAddress( "/chuck/data, i f s s" )" doesn't.
This didn't seem to be an issue when using with OscRev/.event.

Here's the code:
//===========================================
OscIn oIn;
OscMsg oMsg;
6452 => oIn.port;
oIn.addAddress( "/chuck/data, ifss" );

"localhost" => string hostname;
6452 => int port;
OscOut xmit;
xmit.dest( hostname, port );

spork ~ recvOsc();
spork ~ sendOsc();

while(true)
{
1::day => now;
}
//============================================
fun void sendOsc()
{
while( true )
{
xmit.start( "/chuck/data" );
Math.random2( 30, 80 ) => xmit.add;
Math.random2f( 0.1, 1 ) => xmit.add;
"xyz" => xmit.add;
"abc" => xmit.add;
xmit.send();
1::second => now;
}
}
//============================================
fun void recvOsc()
{
-1 => int i;
-1.0 => float f;
"NULL" => string s;
"NULL2" => string s2;
"NULL3" => string s3;
while( true )
{
oIn => now;
while( oIn.recv(oMsg) )
{
oMsg.getInt(0) => i;
oMsg.getFloat(1) => f;
oMsg.getString(2) => s;
oMsg.getString(3) => s2;
<<< "got (via OSC):", i, f, s, s2, s3 >>>;
}
}
}
//=================================================

Thanks
Simon
(PS - my machine is a PC running Windows Vista)

Whenever I try to run ChucK programs on the fly as mentioned in the ChucK Manual, I experience a problem that, Windows says the program ChucK has stopped working. How do rectify this problem?

During my creative process I like to listen to many diffrent sounds others made.

It would be nice to have an open and easy way to share user creations so others can review it and use/improve it. Other options could be a new repository or a branch. My preference goes to a repository as it is easier for users to find and use.

Btw, loving ChucK. Looking forward to making many sounds.

The following code fixes an occasional crash on Linux with chuck_hid when shutting down:

diff --git a/src/util_hid.cpp b/src/util_hid.cpp
index a83f07e..cdedc8d 100644
--- a/src/util_hid.cpp
+++ b/src/util_hid.cpp
@@ -7103,6 +7103,8 @@ void Hid_poll()
                 else if( hcm.action == HID_CHANNEL_QUIT )
                 {
                     close( hid_channel_r );
+                    delete[] pollfds;
+                    delete device_map;
                     return;
                 }

@@ -7124,8 +7126,8 @@ void Hid_quit()

     close( hid_channel_w );

-    delete[] pollfds;
-    delete device_map;
+    // delete[] pollfds;
+    // delete device_map;

     g_hid_init = FALSE;
 }

When I try running chuck from Command Prompt in Windows 7 I get this error message "The program can't start because MSVCR100.dll is missing form your computer. Try reinstalling the program to fix this problem."

Hello,

When a ChucK VM is started (with either chuck --loop or chuck --shell), I've noticed that memory isn't being freed when you explicitly remove a shred (as opposed to letting the shred remove itself).

This bug can be seen by placing printf statements in the constructor/destructor functions of a particular ugen (for instance, SinOsc). A testing chuck file could look like this:

SinOsc s => dac; 10::second => now;

Running "+ sine.ck" and letting it remove it self will cause both the ctor and dtor messages to appear. Running "- 1" before the 10 seconds are up will not call the dtor message.

I noticed that in terminal you can run a chuck file without writing the .ck extension
(the next two lines work)
chuck myTest.ck
chuck myTest
but when it is run without the .ck and the file uses me.dir() that function returns an empty array instead of the correct path.

I'm trying to set up OSC communication between chuck and python-osc. It appears that the messages we send from the python side do not arrive at the chuck side. All other combinations, i.e. python to python, chuck to chuck and chuck to python are working fine though.
I'm running python 3.4.4 on windows 7.
What could be going wrong here?

Here are the four files with the client/server implementations I'm using for testing.

chuck_client.py:

OscSend xmit;
xmit.setHost("localhost", 5005);
<<<"Sending">>>;
xmit.startMsg("/debug");

chuck_server.py:

OscRecv orec;
5005 => orec.port;
orec.listen();
orec.event("/debug") @=> OscEvent e;

<<<"Waiting">>>;
e => now;
<<<"Received">>>;

python_client.py:

from pythonosc import osc_message_builder
from pythonosc import udp_client

client = udp_client.UDPClient('localhost', 5005)
msg = osc_message_builder.OscMessageBuilder(address="/debug")
msg = msg.build()
print('Sending')
client.send(msg)

python_server.py:

from pythonosc import dispatcher
from pythonosc import osc_server

dispatcher = dispatcher.Dispatcher()
dispatcher.map("/debug", lambda _: print('Received'))

print('Waiting')
server = osc_server.ThreadingOSCUDPServer(
    ('localhost', 5005), dispatcher)
print("Serving on {}".format(server.server_address))
server.serve_forever()

"x".substring(1) errors out for me with an out of bounds exception. I find this unexpected, as translating that code to Python, Ruby, Emacs Lisp, etc. gives me an empty string as result. Is this a bug or expected behaviour?