[Bluemusic-users] Automation problems - am I missing something?
Brought to you by:
kunstmusik
From: Steven Y. <ste...@gm...> - 2008-02-28 05:41:07
|
Hi Bernard, Yes, regarding parameters, if they are set to automate they will generate as gk-signals and if not set to automate they will generate as the value in text (i.e. 3.05053). This is partly for efficiency and partly due to legacy coding from when before there was automation. When automation was created, I had put in notes to be careful about this change and that if you had a prior instrument that was not automated that became automated, one would need to be very careful that the csound code be valid and be able to take in a krate sig. I don't think I can change the situation much due to legacy project concerns. I recommend now that one assume the signal is going to be generated as a krate sig and code in csound with that assumption. As for the stair-stepping, if you're interested in looking at the implementation to see if a faster way to generate the stair-stepped values is possible that would be awesome. I don't think it's particularly good code there but it is at least currently accurate, but would invite any other eyes on the code. If you are interested, contact me off list and I can help get you setup to work on blue within an IDE like Eclipse or Netbeans and also can direct you to the stairstepping code in CSDRender. Thanks! steven On Tue, Feb 26, 2008 at 3:03 AM, Bernard Hurley <be...@ph...> wrote: > Hi Steve, > > Thanks, I was about to email the list to say that I had just realised > this. Obviously blue had not crashed - it was just taking an inordinate > amount of time to generate the CSD file. Thanks for the hint about > turning resolution off. The documentation mentions "no resolution", but > I couldn't find anything about setting it to -1. > > I think it is probably not a good idea simply change the code so that > sweep is used instead of stair-stepping when it seems reasonable to the > blue developer - at least not without allowing the old behaviour as an > option. Doing this might break projects that depend on stair-stepping - > for instance to get a tremolo effect. > > Since automation creates an "automation instrument", the system could be > made more flexible if some sort of (limited) editing facilities for this > instrument were possible. I will have a look into this if you wish. I > haven't looked at java for 4 years - I used to teach java (actually EJBs > and J2EE servers to people working for banks etc.) so I should be able > to pick it up again, if you show me where to look. > > One extra point. It is possible to, in effect, automate i-rate variables > if you do something like: > ival init i(<kval>) > However, in this case, the parameter has to be automated. If the > instrument exists unautomated, then code like: > ival init i(3) > is generated, which is illegal in Csound. I realise this is a Csound > issue - there is no obvious reason why this code should be illegal. > however it may be possible to code round it in blue. > > Cheers, > > Bernard > > > > On Mon, 2008-02-25 at 23:34 -0800, Steven Yi wrote: > > Hi Bernard, > > > > The problem I'm finding is that you are automating a widget which has > > .1 resolution but over a very large range. What blue does when it > > creates an automation and resolution is found is to create a note very > > every possible value on that line between the points. At .1 > > resolution and sweeping between 1500 and 3000 as it was in the file > > would mean creating a few thousand notes per section of automation. > > The code to create stairstepped values is not terribly efficient but > > it it is accurate as far as I can tell. (If anyone wants to take a > > stab at the code I can direct you to it.) Normally for large ranges I > > recommend not using resolution (-1) so that the values will not be > > stair stepped. > > > > My take on the problem is that if you're using a large range with > > small resolution, likely that smooth values are more desirable then > > stair-stepped values. Therefore it hasn't been too much of a priority > > to get that changed. If switching resolution is not going to work for > > you, please file a bug and I'll try to take a stab at it when I can. > > > > Thanks, > > steven > > > > > > |