From: David T. <dav...@gm...> - 2013-03-06 15:00:52
|
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, < ros...@li...> wrote: > Send Rosegarden-devel mailing list submissions to > ros...@li... > > 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 > ros...@li... > > You can reach the person managing the list at > ros...@li... > > 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" <ros...@gm...> > Subject: Re: [Rosegarden-devel] 16th note triplet loses its 3 in this > beaming incident > To: ros...@li... > Message-ID: <513...@gm...> > 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 <or...@le...> > Subject: [Rosegarden-devel] Gain problem with audio panning > To: ros...@li... > Message-ID: <513...@le...> > 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 <ho...@ma...> > Subject: Re: [Rosegarden-devel] Gain problem with audio panning > To: Tim Munro <or...@le...> > Cc: ros...@li... > Message-ID: <alp...@fs...> > 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 <te...@te...> > Subject: Re: [Rosegarden-devel] Gain problem with audio panning > To: ros...@li... > Message-ID: <513...@te...> > 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" <ros...@gm...> > Subject: Re: [Rosegarden-devel] Gain problem with audio panning > To: ros...@li... > Message-ID: <513...@gm...> > 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 <or...@le...> > Subject: Re: [Rosegarden-devel] Gain problem with audio panning > To: ros...@li... > Message-ID: <513...@le...> > 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 <te...@te...> > Subject: Re: [Rosegarden-devel] Gain problem with audio panning > To: ros...@li... > Message-ID: <513...@te...> > 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 <ca...@al...> > Subject: Re: [Rosegarden-devel] Gain problem with audio panning > To: Tim Munro <or...@le...> > Cc: ros...@li... > Message-ID: > < > CAJ...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > On 6 March 2013 02:50, Tim Munro <or...@le...> 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 > Ros...@li... > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel > > > End of Rosegarden-devel Digest, Vol 82, Issue 2 > *********************************************** > |