Thanks for your suggestions.

$ chuck --version

chuck version: 1.3.5.2 (chimera)
   microsoft win32 : 32-bit
   http://chuck.cs.princeton.edu/
   http://chuck.stanford.edu/

$ pwd
/c/Users/Chiel.tenBrinke/Projects/chugins/Debug

$ chuck  --chugin:SystemTime ../SystemTime/SystemTime-test.ck
Segmentation fault

$ chuck --chugin-path:.  ../SystemTime/SystemTime-test.ck
Segmentation fault

$ chuck   ../SystemTime/SystemTime-test.ck
# No output, loads just fine

Btw, the reason I specified both was because I don't know how chuck knows the folder with the manually compiled chugins. I suppose it just looks at the current directory though.
Namely, crawling up a level in the directory structure for instance (i.e. to the repo root) results in

$ pwd
/c/Users/Chiel.tenBrinke/Projects/chugins

$ chuck  --chugin:SystemTime SystemTime/SystemTime-test.ck
# No output, loads just fine

I'm not sure what happens there. Is there a way to have chuck be more verbose about which chugins are loaded from where?

On Wed, May 11, 2016 at 2:54 AM, Spencer Salazar <spencer@ccrma.stanford.edu> wrote:
Hi Chiel,

Hmm, maybe make sure you have the latest version of chuck (1.3.5.2). Your chugin works fine for me on Mac and also on Visual Studio 2015/Windows 7. 

Looking at the code, I dont see anything that would cause any problems. This might be problematic though: 
chuck --chugin-path:. --chugin:SystemTime 

This will cause SystemTime.chug to be loaded twice, once when it is found on the specified chugin path and again when it is specified by --chugin. ChucK should not double-load chugins like this, so thats a bug, but see if you get different results with only one of --chugin-path:. or --chugin:SystemTime. 

spencer


On Mon, May 9, 2016 at 1:58 AM, Chiel ten Brinke <ctenbrinke@gmail.com> wrote:
Thanks for the pointers. I've been looking into it.

I'm currently hitting a wall though with developing a simple chugin. It seems that loading any manually compiled chugins immediately result in a segmentation fault.
I'm using Visual Studio 2015 on windows 7. Is this any known problem?


Here's a more detailed case:

Source file (compiles fine):

#include "chuck_dl.h"
#include "chuck_def.h"

#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <math.h>


CK_DLL_SFUN(systemtime_getFreq);

t_CKFLOAT getFreq() { return 4.0; }

CK_DLL_QUERY(SystemTime)
{
    QUERY->setname(QUERY, "SystemTime");

    QUERY->begin_class(QUERY, "SystemTime", "Object");
    QUERY->doc_class(QUERY, "System time support");

    QUERY->add_sfun(QUERY, systemtime_getFreq, "float", "freq");
    QUERY->doc_func(QUERY, "Oscillator frequency [Hz]. ");

    QUERY->end_class(QUERY);

    return TRUE;
}


CK_DLL_SFUN(systemtime_getFreq)
{
    RETURN->v_float = getFreq();
}


Command to run:

$ cd chugins/Debug
$ chuck --chugin-path:. --chugin:SystemTime ../SystemTime/SystemTime-test.ck
Segmentation fault

Where SystemTime-test.ck maybe any trivial chuck script.

You can also view the commit that contains this test code here: https://github.com/Chiel92/chugins/commit/9d49c0713ca9918a3e5b71e4a38f84e0ad02e464

On Wed, May 4, 2016 at 10:05 AM, Iain Emsley <iain.emsley@kellogg.ox.ac.uk> wrote:
Hi  Chiel, 

The Github for the Chugging is here:

and the extension part of the ChucK site has some notes:

There is a paper describing the extension system here:

The chuginate code in the repo may provide some additional notes as well in the code comments. 

Kind regards, 

Iain

Iain Emsley

Research Associate
Oxford e-Research Centre
University of Oxford 




On 4 May 2016, at 08:12, Chiel ten Brinke <ctenbrinke@gmail.com> wrote:

Is there a place where this stuff is documented? I can't find anything about it on the website http://chuck.cs.princeton.edu/doc/program/

On Wed, May 4, 2016 at 2:19 AM, Spencer Salazar <spencer@ccrma.stanford.edu> wrote:
I think the best way to do this is with a chugin. If you know any C++ it would be very easy to write a chugin that simply wraps C time() or whatever OS-dependent function gives you time in milliseconds or nanoseconds. 

Time in programming languages is a surprisingly complex topic (see e.g. [1]); the design of ChucK's now concept (in my opinion, smartly) has no external notion of time, avoiding these issues. Putting this in a chugin would make it a lot easier to grow to the appropriate level of complexity. 

spencer



On Tue, May 3, 2016 at 1:33 AM, Chiel ten Brinke <ctenbrinke@gmail.com> wrote:
The problem with this approach, though, is that it apparently takes a few seconds before the input is processed and the internal chuck timer starts counting.
This results in that the times printed by the suggested code always is a few seconds too early. This makes this approach not quite useful for tracking down latency problems.

Is there a way around this caveat, or are there other approaches to print full time?

On Tue, May 3, 2016 at 9:54 AM, Chiel ten Brinke <ctenbrinke@gmail.com> wrote:
Here is an improvement over the provided script:

class FullTimeHack
{
    int minutes;
    int seconds;

    // PRECONSTRUCTOR

    string datetime;
    ConsoleInput stdin;     // gonna read from here
    stdin.prompt("") => now; // wait until something comes in
    while (stdin.more())  {  stdin.getLine() => datetime;  } // read input
    //<<< datetime >>>;
    Std.atoi(datetime.substring(10, 2)) => minutes;
    Std.atoi(datetime.substring(13, 2)) => seconds;
    <<< minutes + ":" + seconds >>>;


    fun void print_full_time()
    {
        (seconds + now/second) % 60 => float new_seconds;
        (minutes + now/minute) $ int % 60 => int new_minutes;
        <<< new_minutes + ":" + new_seconds >>>;
    }

}

FullTimeHack hack;
hack.print_full_time();


On Mon, May 2, 2016 at 6:11 PM, Chiel ten Brinke <ctenbrinke@gmail.com> wrote:
Thanks for you response. I'm gonna try that out right away,

By the way, wouldn't it be nice if this could be done more easily? Especially since ChucK is really into all the timey wimey stuff :)


On Mon, May 2, 2016 at 10:56 AM, Gonzalo <gonzalo@dense13.com> wrote:
I had a similar problem a while ago, Perry Cook suggested this, it might be of help:

One way to do it would be to pass it in
as an argument or other when you run ChucK.
This example uses stdin to read the output
of a <date> command in the shell:

// TestDate.ck  Perry R. Cook, Dec. 2014
ConsoleInput stdin;     // gonna read from here
stdin.prompt("") => now; // wait until something comes in
string datetime; // date and time
string datetimenow; // plus time since chuck invoked tacked on
while (stdin.more())  {  stdin.getLine() => datetime;  } // read input
datetime.setCharAt(9,'-'); // replace time string colons
datetime.setCharAt(12,'-'); // with dashes instead
datetime+"-"+Std.ftoa(now/second,4) => datetimenow; // tack on time since chuck invoked
<<< datetimenow >>>;
// If you want to continue making updated unique
// strings, just keep redoing the datetimenow line
1.5*second => now;
datetime+"-"+Std.ftoa(now/second,4) => datetimenow; // tack on time since chuck invoked
<<< datetimenow >>>;

To use this:

date +"%m%d%y-%T" | chuck TestDate.ck

Outputs (date-H-M-S-now):

"120614-15-00-09-0.0000" : (string)
"120614-15-00-09-1.5000" : (string)




On 2/05/2016 9:53 AM, Chiel ten Brinke wrote:
I would like to figure out the source of latency from chuck interacting
with another application via OSC. To do that, I want to print timestamps
of messages sent and received and compare these.
But here's the thing:

How do I print the absolute current time in chuck? The variable `now`
only seems to hold the time from the start of the process.


_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users


--
http://dense13.com
http://www.whole-play.com
https://www.30daygroove.com
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users




_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users




--
Spencer Salazar
Doctoral Candidate
Center for Computer Research in Music and Acoustics
Stanford University



_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users


_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users


_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users



_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users




--
Spencer Salazar
Doctoral Candidate
Center for Computer Research in Music and Acoustics
Stanford University

+1 831.277.4654


_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users