[chuck-users] print absolute time in chuck
Spencer Salazar
spencer at ccrma.stanford.edu
Tue May 10 20:54:38 EDT 2016
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 at 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 at kellogg.ox.ac.uk
> > wrote:
>
>> Hi Chiel,
>>
>> The Github for the Chugging is here:
>> https://github.com/ccrma/chugins
>>
>> and the extension part of the ChucK site has some notes:
>> http://chuck.stanford.edu/extend/
>>
>> There is a paper describing the extension system here:
>> https://ccrma.stanford.edu/~spencer/publications/CCC2012.pdf
>>
>> 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 at 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 at 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
>>>
>>> [1]
>>> http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>>>
>>>
>>> On Tue, May 3, 2016 at 1:33 AM, Chiel ten Brinke <ctenbrinke at 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 at 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 at 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 at 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 at 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 at lists.cs.princeton.edu
>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> chuck-users mailing list
>>>> chuck-users at 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
>>>
>>> spencer at ccrma.stanford.edu
>>> +1 831.277.4654
>>> https://ccrma.stanford.edu/~spencer/
>>>
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at 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
spencer at ccrma.stanford.edu
+1 831.277.4654
https://ccrma.stanford.edu/~spencer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20160510/d39633c2/attachment-0001.html>
More information about the chuck-users
mailing list