Hi all,
I often wish I could contribute but I don't code. I am an end user of
Rosegarden and help other users out from time to time. This may be a
ridiculous question. How hard would it be to learn qt with no programing
background? I teach Linux at the local community college. I am very
comfortable configuring servers from their text files and am ok with bash
scripting. I haven't thought about algebra in 30+ years. My only purpose in
learning qt would be to help with Rosegarden. A pipe dream? Too
overwhelming with no coding background? There are definitely times of year
when my time is really limited so it may be a moot point if it would
require lots of time.
Thanks for your thoughts.
Dave
On Wed, Mar 6, 2013 at 5:35 AM, <
[email protected]> wrote:
> Send Rosegarden-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rosegarden-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: 16th note triplet loses its 3 in this beaming incident
> (D. Michael McIntyre)
> 2. Gain problem with audio panning (Tim Munro)
> 3. Re: Gain problem with audio panning (Holger Marzen)
> 4. Re: Gain problem with audio panning (Ted Felix)
> 5. Re: Gain problem with audio panning (D. Michael McIntyre)
> 6. Re: Gain problem with audio panning (Tim Munro)
> 7. Re: Gain problem with audio panning (Ted Felix)
> 8. Re: Gain problem with audio panning (Chris Cannam)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 03 Mar 2013 20:33:23 -0500
> From: "D. Michael McIntyre" <[email protected]>
> Subject: Re: [Rosegarden-devel] 16th note triplet loses its 3 in this
> beaming incident
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/03/2013 05:42 PM, Clem, Brian T. wrote:
>
> > I am wanting to take a tied 8th note on 2 and beam the following 16th
> note triplet. When doing so, I lose my 3 under the triplet. I have to
> untie the 8th notes (+2) (+)(2) then beam the notes on beat 2, then retie
> the 8th note on the + of 1.
>
> So using the procedure you documented with untying and retying and so
> on, you eventually get it to come out right?
>
> If you can eventually get the intended result, that's about the best we
> can hope for, really. The notation editor is impressively hard to
> understand and tinker with, and we have a large number of similar bugs
> that really exist and just have no hope of ever being solved in this
> lifetime.
>
> In a lot of cases, even though Rosegarden does a bad job of rendering
> something, it manages to come out fine on paper through LilyPond.
> --
> D. Michael McIntyre
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 05 Mar 2013 08:55:51 -0800
> From: Tim Munro <[email protected]>
> Subject: [Rosegarden-devel] Gain problem with audio panning
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I've noticed in the Audio Mixer when panning an audio source, the overall
> gain
> also changes, and the level control must be adjusted to compensate. A
> look at
> src/sound/AudioProcess.cpp makes clear what's going on:
>
> 481: rec.gainLeft = volume * ((pan > 0.0) ? (1.0 - (pan / 100.0)) :
> 1.0);
> 482: rec.gainRight = volume * ((pan < 0.0) ? ((pan + 100.0) / 100.0) :
> 1.0);
>
> What all this means is that when
>
> pan = -100
> rec.gainLeft = volume * 1.0
> rec.gainRight = volume * 0
>
> pan = -50
> rec.gainLeft = volume * 1.0
> rec.gainRight = volume * 0.5
>
> pan = 0
> rec.gainLeft = volume * 1.0
> rec.gainRight = volume * 1.0
>
> pan = 50
> rec.gainLeft = volume * 0.5
> rec.gainRight = volume * 1.0
>
> pan = 100
> rec.gainLeft = volume * 0
> rec.gainRight = volume * 1.0
>
> Clearly there is a 3dB drop in overall gain when the control is moved off
> center to one side or the other.
>
>
> My proposed fix, which is fairly straightforward, looks like this:
>
> rec.gainLeft = volume * sqrtf(fabsf((100.0 - pan) / 100.0));
> rec.gainRight = volume * sqrtf(fabsf((100.0 + pan) / 100.0));
>
> which means that when
>
> pan = -100
> rec.gainLeft = volume * sqrt(2.0)
> rec.gainRight = volume * 0
>
> pan = -50
> rec.gainLeft = volume * sqrt(1.5)
> rec.gainRight = volume * sqrt(0.5)
>
> pan = 0
> rec.gainLeft = volume * 1.0
> rec.gainRight = volume * 1.0
>
> pan = 50
> rec.gainLeft = volume * sqrt(0.5)
> rec.gainRight = volume * sqrt(1.5)
>
> pan = 100
> rec.gainLeft = volume * 0
> rec.gainRight = volume * sqrt(2.0)
>
> This maintains constant audio power as the source is panned.
>
> It is because the audio power increases as the square of the level that the
> gain here is multiplied by by the square root of the desired audio power
> gain.
> (In electronic terms, simply doubling the voltage would also double the
> current, resulting in a quadrupling of the power, which we don't want.)
>
> The "fabs()" function is just a reflection of my paranoia.
>
> I have used this modification for some months now and have found it
> indispensable, as it greatly simplifies the operation of the panning
> controls.
> It does, however, come with a minor down side: it breaks (or at least
> bends)
> every Rosegarden composition ever written that relies on the current broken
> behavior.
>
> This obviously warrants some discussion before adoption. Thoughts?
>
> Tim Munro
>
>
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: fix_audio_panning_patch
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Mar 2013 18:24:54 +0100 (CET)
> From: Holger Marzen <[email protected]>
> Subject: Re: [Rosegarden-devel] Gain problem with audio panning
> To: Tim Munro <[email protected]>
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Tue, 5 Mar 2013, Tim Munro wrote:
>
> > Clearly there is a 3dB drop in overall gain when the control is moved off
> > center to one side or the other.
>
> AFAIK that's common practice in most audio equipment.
> >
> > My proposed fix, which is fairly straightforward, looks like this:
> >
> > pan = -100
> > rec.gainLeft = volume * sqrt(2.0)
> > rec.gainRight = volume * 0
> >
> > pan = -50
> > rec.gainLeft = volume * sqrt(1.5)
> > rec.gainRight = volume * sqrt(0.5)
> >
> > pan = 0
> > rec.gainLeft = volume * 1.0
> > rec.gainRight = volume * 1.0
> >
> > pan = 50
> > rec.gainLeft = volume * sqrt(0.5)
> > rec.gainRight = volume * sqrt(1.5)
> >
> > pan = 100
> > rec.gainLeft = volume * 0
> > rec.gainRight = volume * sqrt(2.0)
> >
> > This maintains constant audio power as the source is panned.
>
> > This obviously warrants some discussion before adoption. Thoughts?
>
> Is there a chance to make it configurable, e.g. with a button "constant
> audio power when panning" in the audio configuration section?
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 05 Mar 2013 15:04:14 -0500
> From: Ted Felix <[email protected]>
> Subject: Re: [Rosegarden-devel] Gain problem with audio panning
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/05/2013 11:55 AM, Tim Munro wrote:
> > Clearly there is a 3dB drop in overall gain when the control is moved
> off center to one side or the other.
>
> -3dB Pan Law is a compromise between the other two popular laws, 0dB,
> and -6dB. We could indeed offer a switch to select 0dB, -3dB, or -6dB.
> That would let the user work in their preferred way.
>
> http://forums.presonus.com/posts/list/10230.page
>
> Work up the math, add a config variable (audioPanLaw?), and hook it
> into the config dialog ("Audio Pan Law"). Default to -3. Shouldn't be
> too hard.
>
> Ted.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 05 Mar 2013 16:29:02 -0500
> From: "D. Michael McIntyre" <[email protected]>
> Subject: Re: [Rosegarden-devel] Gain problem with audio panning
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/05/2013 03:04 PM, Ted Felix wrote:
>
> > Work up the math, add a config variable (audioPanLaw?), and hook it
> > into the config dialog ("Audio Pan Law"). Default to -3. Shouldn't be
> > too hard.
>
> I agree this is a good candidate for a config variable that defaults to
> the current -3 behavior. We have the math for two out of three. I
> wouldn't begin to even try to get my head around working out how to do
> the -6 dB option, being basically bereft of math skills, but I'm good
> for knocking together the GUI side of things if anybody would like help
> with that.
> --
> D. Michael McIntyre
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 05 Mar 2013 18:50:20 -0800
> From: Tim Munro <[email protected]>
> Subject: Re: [Rosegarden-devel] Gain problem with audio panning
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> D. Michael McIntyre wrote:
> > On 03/05/2013 03:04 PM, Ted Felix wrote:
> >
> >> > Work up the math, add a config variable (audioPanLaw?), and
> hook it
> >> > into the config dialog ("Audio Pan Law"). Default to -3. Shouldn't
> be
> >> > too hard.
> > I agree this is a good candidate for a config variable that defaults to
> > the current -3 behavior. We have the math for two out of three. I
> > wouldn't begin to even try to get my head around working out how to do
> > the -6 dB option, being basically bereft of math skills, but I'm good
> > for knocking together the GUI side of things if anybody would like help
> > with that.
> > -- D. Michael McIntyre
>
> I agree that any change to Rosegarden's panning should be switchable and
> should default to the current behavior.
>
> Currently Rosegarden appears to be using a form of the so-called 0dB Pan
> Law
> that results in a monaural channel being considerably louder when panned
> to the
> center than when panned to either side. When I first read the code, I
> assumed
> it was a mistake, but I guess people actually do this sort of thing
> intentionally.
>
> From what I've read, I'm not sure that OdB, -3dB, or -6dB setups would be
> useful for what I need to do. But because there seems to be little
> standardization concerning how these laws are implemented, I might be able
> to
> configure a -3dB panning law to provide constant power (constant sum of the
> squares of the channel levels). I have found that a constant-power scheme
> delivers exactly what I need, as I no longer have to readjust a fader every
> time I move something.
>
> I have found Rosegarden's existing behavior extremely awkward, since I use
> the
> panning controls to position monaural sound sources on an imaginary stage.
> Every time I would move something, I would disturb the tonal balance of the
> composition. Some organ compositions that I worked on a while ago
> illustrate
> the point:
>
> Polyphonic organ music will typically have several independent voices
> played on
> the same manual at the same time. With Rosegarden this means assigning
> each of
> these voices a to a different segment, even though they originate from the
> same
> keyboard.
>
> I could easily have assigned the same instrument (representing a certain
> stop
> combination) to each of these segments but chose, instead, to assign a
> completely different instance of the same instrument to each. That way I
> could
> pan the individual identical instruments, thereby hinting at the spacial
> diversity that would be evident in an actual pipe organ installation.
> (This is
> a lot easier than reworking a sound font to specify the position of each
> individual pipe!)
>
> In this case maintaining the balance between the various voices was
> absolutely
> critical to the structure of the pieces but nearly impossible to pull off
> using
> Rosegarden's original configuration. That's what finally drove me to do
> something about it.
>
> I hope that someone else might actually find such a feature useful, and
> that it
> wouldn't serve only to add more clutter and confusion to an already
> complicated
> project.
>
> Tim Munro
>
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 06 Mar 2013 00:09:05 -0500
> From: Ted Felix <[email protected]>
> Subject: Re: [Rosegarden-devel] Gain problem with audio panning
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/05/2013 09:50 PM, Tim Munro wrote:
> > I hope that someone else might actually find such a feature useful, and
> that it
> > wouldn't serve only to add more clutter and confusion to an already
> complicated
> > project.
>
> This feature should be very straightforward. I don't think it will
> have any sort of negative impact at all. It's easy to grasp quite
> quickly. I could see two functions:
>
> double leftPanAmp(double pan);
> double rightPanAmp(double pan);
>
> They take a pan value (-100 to 100) and return appropriate channel
> amplitudes. Maybe normalized 0-1 or something similar which is easily
> converted to whatever is needed.
>
> These two would need to share the audioPanLaw value (-6, -3, 0) from
> the config file. That could be cached someplace, or the whole thing
> could be wrapped up in a class. Probably just a PanLaw utility class
> with statics to avoid the need to create an object. Something like this:
>
> class PanLaw
> {
> public:
> // pan = -100 (Left) to 100 (Right)
> // returns normalized amplitude (1.0 = unity gain)
> static double leftAmp(double pan);
> static double rightAmp(double pan);
>
> private:
> // Called by the above. Initializes values from config
> // if needed.
> static void init() {
> if (!initialized) {
> audioPanLaw = value from config;
> initialized = true;
> }
> }
>
> static bool initialized = false; // in the .cpp, actually
> // Or maybe an enum?
> static double audioPanLaw;
> };
>
> Lots of options, but in the end, the concepts are simple, so this
> should be pretty painless. Even if there is a special case that we need
> that doesn't exactly fit the usual definitions, that can be added to
> this PanLaw class and explained in the comments.
>
> Ted.
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 6 Mar 2013 10:08:31 +0000
> From: Chris Cannam <[email protected]>
> Subject: Re: [Rosegarden-devel] Gain problem with audio panning
> To: Tim Munro <[email protected]>
> Cc: [email protected]
> Message-ID:
> <
> cajmyd7t8pg6kqoolxefp-awdxuehu67pu2t-9npvbwiar6r...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 6 March 2013 02:50, Tim Munro <[email protected]> wrote:
> > Currently Rosegarden appears to be using a form of the so-called 0dB Pan
> Law
> > that results in a monaural channel being considerably louder when panned
> to the
> > center than when panned to either side. When I first read the code, I
> assumed
> > it was a mistake, but I guess people actually do this sort of thing
> > intentionally.
>
> As far as I'm concerned, the current code has always been a bit
> useless -- a consequence of someone (was it me, back in the day? not
> sure... if so I apologise) doing what seemed obvious without giving it
> enough thought. The main reason it has never changed is just inertia
> based on there already being sessions out there using the existing
> behaviour.
>
> One thing I'd say though is that this sort of thing really must be
> part of the saved document, not just part of the application settings.
> There could *be* an application setting, but it would have to be a
> default for new documents rather than a fixed setting for every
> document. It's not really OK to have sessions changing their mix
> balance without warning when saved and reloaded.
>
> At the very least, RG should know enough to be able to warn when a
> session is reloaded with a different pan setting (or when a session
> made before the setting was added is reloaded with a setting different
> from the former default).
>
> > From what I've read, I'm not sure that OdB, -3dB, or -6dB setups would be
> useful for what I need to do.
>
> I *think* that what's usually referred to as a -3dB law is actually
> what you have -- i.e. -3dB in power rather than voltage. (as
> 10^(-3/20) == 1/sqrt(2)) Probably should check what other software
> thinks though, which I can't readily do just at the moment.
>
> (However, it should attenuate in the centre rather than boost at the
> edges -- otherwise you can load a normalised file, pan it, and it
> clips.)
>
>
> Chris
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
>
> ------------------------------
>
> _______________________________________________
> Rosegarden-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
>
>
> End of Rosegarden-devel Digest, Vol 82, Issue 2
> ***********************************************
>
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
