On August 26, 2012 1:50:42 PM Florian Jung wrote:
> Am 25.08.2012 10:48, schrieb Tim E. Real:
> > Editor Canvases and local copies of Song cursors:
> > -------------------------------------------------
> > Until now, class Canvas had three simple unsigned integers describing
> >
> > the Song cursors, which were local copies of either the cursor frame
> > or tick values. Since each Canvas had either fixed frame or tick time
> > scales, unsigned values were good enough.
> >
> > These have now been replaced by true instances of class Pos.
>
> why are there at all local copies? can't we just access
> MusEGlobal::song's instances through mutex-locked setter- and getter
> functions?
Hi Flo. How's it going?
Yes good point, I remember you asked a long time ago why we had local copies.
Not exactly sure why. I suppose they could be removed and the Song cursors
queried directly upon reception of setPos signal.
Trying to think of reasons why not...
>
> > Snap combo boxes:
> > -----------------
> > In Frames mode it would be say "1 2 4 8 16 32 64 128" etc.
>
> why not also 44100, 22050, 11025 etc? (or depending on our projects
> sampling rate?)
Yes, those were just examples.
The reality is for FRAMES and TICKS or even MSF mode we really need a
user entry box to allow exact number of frames or samples snapping
because I figure otherwise the snap box will have to have a lot of values,
but certainly populate it with several handy values including as you say the
sample rate is a good idea.
In Minute/Second/Frame mode, Pos and our controls currently actually
support Minute/Second/Frame/Subframe, where Subframe is in units
of 1/100 of a frame.
I should point out here there is potential for misnomer confusion here:
What MusE's Pos class (and audio talk in general) calls a 'FRAME' really
should be called 'SAMPLE' or something because a MSF frame is not
the same thing: A MSF frame's units depends on the Midi Time Code
type (1/24, 1/30 etc) and the sample rate.
These 1/24 1/30 etc units are handy SMPTE units, else in pure FRAMES
mode the numbers are very large like 44100 / second.
Even with 1/100 Subframe support, each of those units still contains
a lotta samples.
>
> > Time Locking, Wave Parts and Events, and Midi Parts and Events:
> > ----------------------------------------------------------------
> > Also, this means 'mixed' Part and Event time types in the PartList and
> >
> > EventList classes!
> >
> > When sorting, the lists determine whether to use FRAMES or TICKS depending
> >
> > on the 'Time Lock' setting.
> >
> > CLARIFY: Last sentence I'm not sure about - Events yes, but sort Parts
> > how?
>
> do you mean that one MIDI part may contain both FRAME-located and
> TICK-located events? i'd not allow mixing them within a single part.
Yes, sorry my mistake there.
At no time should the Events list require /mixed/ event time types.
They must all either be FRAMES or TICKS time type, dictated by the
Part time type and changeable by the user. This applies to both
Wave Parts and Midi Parts.
So, I'm not sure how we would sort this mixed time type Part list.
We need an index. When the multimap goes to sort, how do we
determine whether to take the Part's FRAME vs TICK value as an index?
Dual Part lists - one containing FRAME Parts, the other TICK Parts?
For that matter how the heck do we find() something - find() takes a tick!
For the Event lists, we would look to the containing Part's time type to
determine whether to read the Events' FRAME or TICK as a sorting index.
Er, I think...
Hm, even though all the events will have the same time type, I guess maybe
we could just ignore the Part's time type there...
But just in case... maybe wiser to look to the Part anyway?
Alas, there may be bits of code dealing with events, which do not know
what Part they came from.
** Or, tell you what: Keep it simple:
Let's ditch the individual Part Time Lock and just go with Track Time Lock.
"Who would need to mix Part time types on a track anyway? Put them in
another track!".
Thus we now have something to look at, the Track Time Lock, to determine
whether to read FRAME or TICK for the indexes of the Part sorting !
And since all the Parts would have the same time type, we might not even
have to look to the Track Time Lock. I guess...
There we go! Track Time Lock!
How's that sound?
(Awww, but I want my Part Time Lock!
Ha - impossible? Not necessary? Overkill? What u think?)
>
> as for the time-lock column: how about replacing this by some popup menu
> entry for the parts in the PCanvas, and different texture schemes for
> the parts? (e.g., solid background color for TICK-aligned parts and
> diagonal lines for FRAME-aligned parts? (like [/////] instead of [ ])
He he, now you're following, yeah thought about that one.
But my thoughts were I already have :::::::: on a white BG for muted parts .
What I have playing in my mind there is a small 'lock', or even a 'clock'
icon at the top left of any part. Yet if the left of the part is offscreen,
we force it to be drawn on the left of the screen (ie in the middle of
the part) so it's always visible to you.
Seems to win in my mind over Yet Another Colour/Hatch scheme,
yet I favour a colour scheme if it can work.
Not sure yet, hoping it kinda falls into place.
(D'oh. Why is it seemingly simple graphics and keyboard issues can hold up
an entire plan?)
About the Track Time Lock: It occurred to me that users might want
to have their parts locked all the time, by default, for quick usage.
Perhaps use it as an override governing all the parts in the track.
>
>
> is it possible to contribute to these infrastructural changes? i'd be
> glad if i could help on some points there; you just would need to tell
> me what, where and possibly how ;)
I've decided that the bit about allowing FRAME/TICK parts will have to
wait at least on my end, there's waaay too many 'tiny back-streets'
of code - mucho sweeping and rewrites needed.
For example at this exact moment (stuck in thought for two days now)
I'm at PartCanvas::resizeItem(). Kinda tricky there, it's what made me
think of the Part FRAMES/TICKS thing. Alas, I need to move on this
so I'm gonna proceed without Part FRAMES/TICKS thing for now.
For now I just want to convert all the code to the Pos stuff and get those
Time Scales up there.
BTW I forgot to mention, the way I am attempting to structure this is
to leave room for the possibility of MULTIPLE Time Scales at the top of
the canvas, you know just like our friends QTractor and Ardour.
>
> these changes sound great, as in clean, btw ;) we should remove all
> these tiny special cases all about MusE and replace by them more general
> stuff (like the TICK- and FRAME- Pos thingy).
Yeah, I think it's the way MusE should be, it seems to make sense.
Much more 'agnostic' or 'pragmatic' about what is a 'position', eh?
Werner and Robert already started this in muse_evolution, but I noticed
there were only /two/ Time Scale modes BBT and MSF.
QTractor and Ardour have the /four/ modes FRAMES, TICKS, BBT and MSF.
To recap, our Time Scales will have /two/ time modes FRAMES and TICKS,
with an extra 'formatted' flag (BBT or MSF), thus giving /four/ modes total.
Positional readouts and edit boxes will support the four modes as well.
"Specifications may change due to boneheaded lack of foresight."
Like right after I write this, ha...
Tim.
>
> greetings
> flo
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
