Fellow ChucKists, Dear Dan, Two minor issues with LiSa.duration(). When we set the recording buffer to any size over 100::second a error will be given. However, the error won't make it clear it's coming from LiSa. In larger .ck files that also involve -for example- fft and the like it becomes a minor chore to detect the source of that warning message. This does not match the behaviour of other UGens and is generally inconvenient so I'd like to suggest pre-pending "LiSa; " to it. Though extremely minor I feel this is a issue. The second point is more subjective and open for debate. I feel that 100::second for the max duration made sense back when LiSa could only .record() but these days we can fill her memory using valueAt() and using longer buffers becomes practical. On top of that loading files straight into LiSa has been hinted at. Are there reasons to not extend this max to 10::minute or something in that order of magnitude? Would there be real issues with setting it to 1::hour and leaving people to shoot their own RAM-foot if and when they really wanted to? We allocate and free this memory properly, right? It is already possible to casually have ChucK blow your RAM out the window if you really wanted to; float foo[1000][1000][1000][1000]; //don't actually run this Yours, Kas.
Two minor issues with LiSa.duration(). When we set the recording buffer to any size over 100::second a error will be given. However, the error won't make it clear it's coming from LiSa. In larger .ck files that also involve -for example- fft and the like it becomes a minor chore to detect the source of that warning message. This does not match the behaviour of other UGens and is generally inconvenient so I'd like to suggest pre-pending "LiSa; " to it. Though extremely minor I feel this is a issue.
fixed this and will commit to CVS.
The second point is more subjective and open for debate. I feel that 100::second for the max duration made sense back when LiSa could only .record() but these days we can fill her memory using valueAt() and using longer buffers becomes practical. On top of that loading files straight into LiSa has been hinted at. Are there reasons to not extend this max to 10::minute or something in that order of magnitude? Would there be real issues with setting it to 1::hour and leaving people to shoot their own RAM-foot if and when they really wanted to? We allocate and free this memory properly, right? It is already possible to casually have ChucK blow your RAM out the window if you really wanted to;
funny, not sure why it's cutting you off at 100::second. it's currently set to allow up to 1000 seconds (>16::minutes!), and that's how it works with my chuck and mA. it may have been set to 100:second for an earlier chuck, but i'm assuming you are at the current chuck, no? best, dan
float foo[1000][1000][1000][1000]; //don't actually run this
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Dan;
fixed this and will commit to CVS.
Great! Thanks!
funny, not sure why it's cutting you off at 100::second. it's currently set to allow up to 1000 seconds (>16::minutes!), and that's how it works with my chuck and mA. it may have been set to 100:second for an earlier chuck, but i'm assuming you are at the current chuck, no?
Whoops, that would be my bad. I run a few versions on various computers and I think this was tested on the ASIO version on my music laptop. The ASIO version is one version out of date and nobody rolled a new one yet. I need to learn how to cross-compile for Windows from GCC so I can roll a Windows ASIO one with the CNoise fix. One speedy fix and one fix with a negative response time. The "strongly timed development award" for the month of December goes to Dan! Thanks, kas.
participants (2)
-
dan trueman -
Kassen