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