Re: [Lmuse-developer] status (and Tim's status)

[Tim E. R. <ter...@ro...>]

On April 29, 2013 08:17:30 AM Florian Jung wrote:
> Am 29.04.2013 03:19, schrieb Tim E. Real:
> > But as I posted earlier I'm a bit frustrated that I must now supply a
> >  password *every* time I want to download or update my local copy
> >  of the new repo - even *every* time I simply open the repo in KdeSvn
> >  simply to examine it !
> > Seems that something still may not be right, I've set up my SSH and so on,
> >  and it still asks for a password when I just want to examine the repo
> >  in KdeSvn.
> 
> does it ask if you use svn commit from the command line? if yes, then
> you did something wrong.
> Does it ask you for your sf.net password, or for the ssh-key passphrase?

Well it's kinda weird. Notice the SF project page presents three options
 for downloading.
If I use the http method it asks for my SF password I think IIRC.
If I use the svn ssh method it asks for my passphrase, I think.

Can't remember exactly.

> 
> > So I'm kind of worried what's going to happen when I finally complete
> >  my (long awaited months-long) current work and sit down and try to
> >  merge - both to and from the new repo.
> > Robert seems to have had no trouble at all committing new stuff,
> >  although that's not the same as what you and I are faced with -
> >  his was fresh new stuff I think, but we both have back-logged material
> >  that needs to be merged - both to and from the new repo.
> 
> did he merge stuff, or just commit into trunk? (Committing to trunk
> works without issues. If someone knows how to merge, tell me!)

I think it was just regular commiting to trunk.

> 
> > Yikes... Sweating and nail-biting in apprehension of impending
> > disaster...?
> 
> it's not THAT bad. read
> svn help diff
> and
> man patch
> (especially the --merge option)
> you can do manual merging by svn diff-ing trunk from revision foo to
> HEAD, and then applying this patch using patch --merge to your branch.
> 
> HOWEVER, this will break svn merging even more.
> 
> i'll need to contact sf.net :/

Mm, dunno maybe there's something not done right see what Robert says first.

-------
Just wanted to say to my dismay I found some flaws in my existing 
 sample-accurate methods (in trunk + released) especially in regards 
 to the automation modes like touch mode.
For example it was possible for it to sound really crappy while operating a 
 control or external midi-to-audio assignment control in say, touch mode, 
 under certain conditions. (If play head was stopped on a section of audio 
 automation graph with a fairly steep slope between two fairly close points.)

So I've finally just solved these problems.
The benefit is that operating controls in all the modes should be better now.
If all goes well you should be able to even override automation READ mode -
 until play-head seek or start play. Even with external controls or GUI 
 controls for which we don't have access to 'pressed' and 'released' signals.
And I cleaned up some silly stuff with pressed/released/adjusted GUI controls 
 and so on.

This is on top of (if you read what I posted recently) speed boosts and fixes,
 including what you pointing out months ago about the sample-accurate
 stuff having potential speed bottle necks.
Including new sample-accurate track and slew-rate limited controllers like 
 volume and pan. Standardized to open the door for easy addition of future 
 controllers like *cross* *fading* and so on.

So all this stuff is audio engine and processing chain fixes and improvements.
Audio engine rewrite number 3 Gazillion. 

I do not believe this should affect your new sub-tick and pos/length branch -
 as it currently stands in regards to audio controllers.
It's just audio processing stuff with improved audio controllers.

----
Now, the other thing I really wanted to say is that while I was in the engine, 
 I made the *meters* stay on all the time *regardless* of muting.
So you guys can now check levels *before* hitting that (un-)mute button to
 let the sound through. 'Tis a small thing but just wanted to let you know.
This kind of thing could be in conjunction with the concept of 
 *monitor* or *cue* outputs, but as I pointed out earlier our tracks are 
 rather 'generalized'. Someone began to include a monitor buffer but it is 
 not used at all. Maybe in the future I can find a way to provide a dedicated
 monitor/cue buss and outputs.

Tim.