2012/7/8 Tim E. Real <[email protected]>:
> On July 8, 2012 12:31:04 PM Robert Jonsson wrote:
>> 2012/7/8 Geoff Beasley <[email protected]>:
>> > how do you guys cope with just a rec_n.wav convention for audio files in
>> > sessions? now that I have to try to find the Bass track waves' to
>> > rebuild after that delete incident it's looming as a real problem.
>>
>> I've changed it so the files have track names and increment their take
>> number individually.
>
> Very nice thank you.
>
> On a parallel note, while recording and editing parts for a song recently
> I was reminded of how nice it might be if the /part/ names were auto-
> incremented, switchable if user desires.
> Taken further, some kind of global renaming function, since after moving
> parts around from track to track until satisfied with the results, it may
> be desirable to rename the parts to fit the actual tracks they're on now.
>
> If we stick to a convention that I came up with for 'Duplicate Track':
> all post-fixes start with '#' like "Track 1 #2"
> then the renaming function might be able to keep the post-fixes
> by keeping everything from the '#' and after.
Sounds like a plan!
>> Had some trouble with localization so I fear it breaks down if the
>> track names have non-english chars in them... so messy.
>
> Yeah I had to review some recently added songfile xml floats and doubles,
> for fear that localization would break them ie 999.00 vs 999,00 etc.
> Actually ints could be affected too, all numbers really.
>
> Remember long time ago when someone reported that the stored audio
> controller data was corrupted because of his localization of doubles?
> And in the save routine I had to add QLocale loc("C"); loc.toDouble(v);
>
> That's what I worry about. However, last week I tried to force MusE to break
> by using the locale switches fr, de, se etc. but nothing happened.
> It's possible Orcan's and everyone's fixes over the years have vanished it.
> Or not...
>
> I recently read this in help QString::toDouble:
>
> "This function tries to interpret the string according to the current locale.
> The current locale is determined from the system at application startup
> and can be changed by calling QLocale::setDefault(). If the string cannot be
> interpreted according to the current locale, this function falls back on the
> "C" locale.
> Due to the ambiguity between the decimal point and thousands group
> separator in various locales, this function does not handle thousands group
> separators. If you need to convert such numbers, see QLocale::toDouble()."
>
> I note that nowhere do we actually call QLocale::setDefault().
> We set the translations yes, but the locale, no. Should we do it?
>
> I saw one routine which I think Orcan fixed, he seemed to use a different
> more proper looking(?) method. Can't find it now.
>
> So I'm confused sometimes about what to do about localization, sometimes
> completely forgetting it.
>
> Do you think we should just set app default "C" so that we don't have to do it
> in all the routines (like the controller data mentioned above)?
> Or just stick with doing it locally in the routines due to the requirement
> mentioned in the help above?
I really don't know. I think that the particular problem with decimal
comma/point is not a problem in the current code.
When doing songfile access we need to keep it that way.
What would setting app default to "C" mean in reality, would it affect
translations?
>> Also the keyboard shortcut now asks before deleting.
>
> Mm, not sure if this a help or hindrance.
> The undo button is supposed to bring them back although it can't
> prevent accidents.
> Maybe add a user setting "ask before deleting parts", and couple it with
> a "don't ask again" (yeah I know, yet another custom dialog, or does Qt
> have such an option I wonder).
>
> Because if we're going to do it for parts, what about notes, and so on?
Indeed, I'm with you.
I just noticed that the fix wasn't quite what I wanted to do. I
thought it would only affect removal of tracks, not removal of parts.
Editing on the canvas needs to be free flowing, definitely.
I agree with Geoff that deleting the actual track should render a
question, I've done that with delete several times and was a bit
surprised when the track disappeared. Undo fixes it though so it's not
the end of the world.
I'll try to fix it.
Regards,
Robert
>>
>> > There is no auditioning mechanism and no meaningful naming convention.
>> > I suggest adding the track name and take number in place of the existing
>> > scheme. ok??
>> >
>> > a wave auditioner would also be nice...
>
> I've always been thinking of a vari-speed scrubber, and a 'pause mode',
> and reverse play too.
> It is possible to completely statically stop and even reverse the midi engine
> while in play mode (zero or negative tempo!).
> It would require some further puzzling support, ie reversing the order
> of playback of note-ons and offs.
> But audio is a different matter. It wants to always 'march' forward, and
> do so in (sometimes long) periods. Been thinking of ways to make it work,
> at least with small periods...
>
> Tim.
>
>>
>> Indeed, that will have to be for another day. It would be very useful.
>>
>> Regards,
>> Robert
>>
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
