Re: [Lmuse-developer] Big list o bugs

[John C. <j4s...@bi...>]

On Monday 03 May 2004 05:18 pm, Robert Jonsson wrote:
> Monday 03 May 2004 22.48 skrev John Check:
-snip-
> >
> > Just want to clarify. Hihats  require monophonic behaviour(as opposed to
> > polyphonic) as stated. When I say groups, generally I mean for
> > convenience, such that port reassignment can be done in bunches. Of
> > these, we can either hardcode some for psuedo-monophony or have a toggle.
> > The grouping itself is more important that monophony.
> > Usage example: Say you're collaborating and the other party uses a
> > whizbang2000 cymbal emulator, which will be in the final product, but
> > it'll be done at your place. On the day of reckoning, the other party
> > brings their WB2k and jacks it in to your system. If we had groups "to
> > port", we only have to make the port reassignment once.
>
> I added this to the Plans page on the wiki.
>

Cool

> <...>
>
> > Heres the thing that lead me to believe implementing
> > this wasn't going to be a  headache: The draw tool already knows
> > when to resize a note as opposed to dropping a new one in. We should be
> > able to use that as the trigger, yes? Why reinvent the wheel?
> > If I'm not recalling the actual behaviour, and it requires the shift key
> > before resize mode is engaged, then use those conditions to change the
> > cursor.
>
> Mmm, ok, I fear I might have made one of my infamous reality distorsions, I
> see that Werner has changed it so the pointer changes /during/ the
> operation is carried out which is quite possible to do. Was this what you
> where after (if so disregard from the following elaboration)?
>

Having a look.. Yes that's pretty close. Since we don't have to grab a handle 
to resize, I'd say it's acceptable.

Thanks Werner!

> I can't find the original mail now, I was however under the impression that
> what you where after was that the pointer should change as soon as the
> mouse entered the area where the new behaviour would take effect. This
> seems to me as being much harder to implement. And, no, the method you
> describe above would not work for this scenario. The draw tool does not
> know what to do until the button is clicked.
>

That's pretty close to what I meant. The implementation I referenced required 
grabbing the trailing edge of the note. The cursor didn't change until you 
were over (or within a pixel of) the "note off". It was also IIRC on the 
select tool, not the draw tool, which would be a nice addition at some point. 
What we have now does the job. There's no mistaking whether a note was 
extended or not, which was why I brought it up to begin with.. 

> /Robert
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Lmuse-developer mailing list
> Lmu...@li...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer