On 04/30/2014 08:49 PM, Tom Breton (Tehom) wrote:
I'm at revision 13676.
That's one revision past what I committed?
Yeah. The revision numbers aren't limited to a single branch.
That's the latest rev on all branches. I guess it's just how svn works.
Anyways, I'm refactoring
I'm getting the following in the big-tuplet-rewrite branch:
In file included from src/base/selections/TempoSelection.h:22:0,
from src/commands/segment/AddTimeSignatureCommand.h:24,
from src/gui/editors/matrix/MatrixView.cpp:65:
On 04/05/2014 05:59 AM, D. Michael McIntyre wrote:
Put the new indices at the end,
Ok.
and just totally ignore the .ts changes, as that stuff will sort it self
out later.
I had a feeling that was the case. It never changes on me, so there
must be some tool that I don't run.
I can
On 04/05/2014 06:47 AM, Ted Felix wrote:
I can take care of this this afternoon or evening (EDT). Unless
someone beats me to it.
Done. r13673.
Ted
On 04/04/2014 05:20 PM, D. Michael McIntyre wrote:
That'll work. Thanks. I'm just stupidly busy right now if somebody
else can process the patch.
I'll have a go at it. Looks straightforward. But there's all this
translation stuff in it. I assume I can ignore that and it will be
On 04/04/2014 05:50 PM, D. Michael McIntyre wrote:
Prompted by that concern, I took a deeper glance. There are problems
with this I don't have time to discuss at the moment. Better just leave
it on the desk a couple more days until I get a breather.
Ok. I applied just the src (and README)
On 04/04/2014 06:21 PM, Ted Felix wrote:
Ok. I applied just the src (and README) changes and it appears to
work fine for my limited testing.
On closer inspection, the shuffling of the indices is going to cause
a misinterpretation of settings. So, if you were using Okular, after
On 03/31/2014 03:12 PM, thomas kaeding wrote:
No, my lirc_client.h does not have ifdef __cplusplus.
Strange. It's been in there since 9/13/1999:
http://sourceforge.net/p/lirc/git/ci/0fe26a512748e88b8593cd09d31cbe3a8c9e8e5e/
Maybe you have a really old version of lirc? Or one that has
On 03/30/2014 07:04 AM, Tim Munro wrote:
extern C {
#include lirc_client.h
}
I am also running gcc 4.8.2 but haven't seen that problem here.
Me either. I've got gcc 4.8.1. Inside lirc_client.h, I see the
following near the top:
#ifdef __cplusplus
extern C {
#endif
So, lirc_client.h
On 03/05/2014 06:33 AM, D. Michael McIntyre wrote:
But... It seems like the kind of thing that could easily be a bug where
bad values are allowed to creep into your stored user setting stuff
So, maybe rename your config settings and see if that clears it up:
$ mv
On 03/04/2014 08:39 AM, D. Michael McIntyre wrote:
Damn I'm having fun!
That, my friend, is what it's all about.
Ted.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce,
On 03/04/2014 10:53 PM, Daren Beattie wrote:
start a new composition, draw
a segment of any length, and try to open it in the notation editor using
any of the three available methods (double-click, toolbar button, or menu).
Rosegarden will promptly abort.
Works fine for me.
Try a make
On 02/25/2014 09:22 AM, D. Michael McIntyre wrote:
Every time I get into this mess I end up
saying hell with it, I may as well just do the thing instead of having
to spend three hours trying to explain it all.
I've been in that situation many times myself. Delegating is hell.
You can
Eugene Crosser:
if you do assign some settings in the command line or from the display-setup
script, something resets them back shortly afterwards.
That would be g-s-d's power plugin. See gpm-common.c,
disable_builtin_screensaver() and
gsd_power_enable_screensaver_watchdog(). g-s-d's power
Eugene Crosser:
if you do assign some settings in the command line or from the display-setup
script, something resets them back shortly afterwards.
That would be g-s-d's power plugin. See gpm-common.c,
disable_builtin_screensaver() and
gsd_power_enable_screensaver_watchdog(). g-s-d's power
I've read through the portions of Xorg that are directly related to the
screensaver timeouts (dixSaveScreens() and friends) and it appears that
my suspicion is incorrect. I was unable to find any sort of built-in
default screensaver. Another dead end.
Then I remembered that the kernel has a
I've read through the portions of Xorg that are directly related to the
screensaver timeouts (dixSaveScreens() and friends) and it appears that
my suspicion is incorrect. I was unable to find any sort of built-in
default screensaver. Another dead end.
Then I remembered that the kernel has a
My (completely unconfirmed) suspicion at this point is that the problem
lies in xorg-server. I'm guessing that xorg-server has a built-in
default screensaver of some sort that turns off the monitor. In 13.04,
this was working fine. In 13.10, it no longer is. I'm going to shift
my focus to
** Also affects: xorg-server
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-greeter in Ubuntu.
https://bugs.launchpad.net/bugs/1245474
Title:
[regression] on login screen, monitor
My (completely unconfirmed) suspicion at this point is that the problem
lies in xorg-server. I'm guessing that xorg-server has a built-in
default screensaver of some sort that turns off the monitor. In 13.04,
this was working fine. In 13.10, it no longer is. I'm going to shift
my focus to
** Also affects: xorg-server
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1245474
Title:
[regression] on login screen, monitor stays on forever
To
Through some script trickery, I was able to get g-s-d running in debug
mode. It appears from the debug output that in 13.04, g-s-d's power
plugin is *not* responsible for powering off the monitor when lightdm
/unity-greeter is up. The question is: Who is?
(Power is out here, probably for a
Through some script trickery, I was able to get g-s-d running in debug
mode. It appears from the debug output that in 13.04, g-s-d's power
plugin is *not* responsible for powering off the monitor when lightdm
/unity-greeter is up. The question is: Who is?
(Power is out here, probably for a
Robert Ancell:
It seems likely the problem is either unity-greeter not configuring / running
the correct plugin in g-s-d
It appears that the power plugin is indeed running in both 13.04 and
13.10 as I am seeing logging from it in /var/log/lightdm/x-0-greeter.log
in both 13.04 and 13.10.
or
Robert Ancell:
It seems likely the problem is either unity-greeter not configuring / running
the correct plugin in g-s-d
It appears that the power plugin is indeed running in both 13.04 and
13.10 as I am seeing logging from it in /var/log/lightdm/x-0-greeter.log
in both 13.04 and 13.10.
or
It turns out that in 13.04, display power-off (when lightdm is up) is
driven by the X screensaver timeouts. If I do this:
xset s 60 60
...in lightdm's display-setup-script, the screen powers off (in 13.04)
in one minute instead of the usual 10.
13.10 has the X screensaver timeouts set to 10
It turns out that in 13.04, display power-off (when lightdm is up) is
driven by the X screensaver timeouts. If I do this:
xset s 60 60
...in lightdm's display-setup-script, the screen powers off (in 13.04)
in one minute instead of the usual 10.
13.10 has the X screensaver timeouts set to 10
Thanks, Eugene. Your solution works for me as well.
To complete this workaround, I've added a script to handle turning off
the X dpms timeouts when the user logs in. Here are the three files
that I've created. First, the config file:
/etc/lightdm/lightdm.conf.d/50-dpms.conf
--- cut here
Thanks, Eugene. Your solution works for me as well.
To complete this workaround, I've added a script to handle turning off
the X dpms timeouts when the user logs in. Here are the three files
that I've created. First, the config file:
/etc/lightdm/lightdm.conf.d/50-dpms.conf
--- cut here
** Also affects: unity-greeter
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1245474
Title:
[regression] on login screen, monitor stays
*** This bug is a duplicate of bug 1245474 ***
https://bugs.launchpad.net/bugs/1245474
** This bug has been marked a duplicate of bug 1245474
[regression] on login screen, monitor stays on forever
--
You received this bug notification because you are a member of Desktop
Packages, which
*** This bug is a duplicate of bug 1245474 ***
https://bugs.launchpad.net/bugs/1245474
** This bug has been marked a duplicate of bug 1245474
[regression] on login screen, monitor stays on forever
--
You received this bug notification because you are a member of Desktop
Packages, which
** Also affects: unity-greeter
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1245474
Title:
[regression] on login screen, monitor stays on forever
To
*** This bug is a duplicate of bug 1245474 ***
https://bugs.launchpad.net/bugs/1245474
** This bug has been marked a duplicate of bug 1245474
[regression] on login screen, monitor stays on forever
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
*** This bug is a duplicate of bug 1245474 ***
https://bugs.launchpad.net/bugs/1245474
** This bug has been marked a duplicate of bug 1245474
[regression] on login screen, monitor stays on forever
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
On 12/16/2013 04:03 AM, Pigeon wrote:
event=battery.*
action=DIEDIEDIE
Thanks for the patch. I will review it today. It sounds like an
interesting feature.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On 12/04/2013 12:11 PM, Tom Breton (Tehom) wrote:
Is it something like this?:
At first, clicking to place notes works fine. At some point you deselect,
and then even though the draw tool is selected, mouse clicks don't do
anything. You select the draw tool again, and it works again.
No,
On 12/04/2013 07:53 AM, D. Michael McIntyre wrote:
On 12/03/2013 10:21 PM, Ted Felix wrote:
(Monitor isn't shutting off in specific subtle situations.)
No it isn't, and IT'S PISSING ME OFF!
You too? I'm digging through gnome-screensaver right now (C and GLib
and D-Bus, oh my!), but I'm
On 12/03/2013 06:22 PM, Tom Breton (Tehom) wrote:
It's also more bulletproof, I hope.
* Handles slivers, ie notes that go just barely across a barline or
other metric line.
* Handles truncated bars, ie where some time-signature has started a
new bar prematurely.
* Almost
On 11/16/2013 05:08 AM, Chris Cannam wrote:
You should definitely mess
around with it even if you never venture outside your most familiar
workflow.
I was thinking of looking for some snippets to use as test cases.
Can anyone recommend specific pieces or composers that would be
On 11/16/2013 02:21 PM, Tom Breton (Tehom) wrote:
Just to throw some public domain examples out there
Perfect. I'll grab the ones you recommend and see about putting them
on a wiki page for reference. Hopefully that will get the ball rolling.
Ted.
On 10/26/2013 08:34 AM, D. Michael McIntyre wrote:
Does anybody have anything in the air right at the moment I should wait
for?
Not me.
Ted.
--
October Webinars: Code for Performance
Free Intel webinars can help
On 10/16/2013 07:33 PM, D. Michael McIntyre wrote:
While I was writing this, Ted committed this (as displayed on SourceForge):
+//if (baseSegmentItr == m_originalSegment.end()) {
+//RG_DEBUG EventSelection::addRemoveEvent():
+// Sent event that can not be found
On 10/11/2013 06:14 PM, Repository Rosegarden code wrote:
Comment out Q_ASSERT, as it is plainly not safe to use in production code.
Yikes. This is not good. I've just verified it. It appears to be a
problem with our configure.ac. This:
RG_DEFINES_RELEASE=-DNDEBUG -DBUILD_RELEASE
On 10/11/2013 07:36 PM, Ted Felix wrote:
Needs to define QT_NO_DEBUG. I'm going to try it out and commit.
Then it should be safe to use Q_ASSERT().
Works. Committed as r13479. Assert away...
Ted.
--
October
On 10/09/2013 07:36 AM, D. Michael McIntyre wrote:
Maybe a checkbox in the
composition start and end dialog to say [x] Do not expand beyond this
point or something like that.
That sounds like a good idea.
If my investigation into expansion during recording provides any
leads, I'll see
Ok, I've seen massive commits go by in the past. And I've got one
that weighs in at several thousand lines. It standardizes all of the
include guards to:
#ifndef RG_NAME_H
#define RG_NAME_H
...where NAME is the name of the class.
Anyone object to a massive commit such as this?
On 09/24/2013 06:11 AM, D. Michael McIntyre wrote:
Rosegarden throws an exception out of src/base/Event.h and Qt complains
that throwing exceptions from an event handler is illegal.
WARNING: Rosegarden::Exception: No data found for property
untupledcount at src/base/Event.h:558
Six calls
This has been fixed in acpid 2.0.20 just released today.
http://sourceforge.net/projects/acpid2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 09/12/2013 08:19 PM, Tom Breton (Tehom) wrote:
If I remember correctly, those all come from the way MappedEvent stores
text events, sysex events, etc. I bumped into this strange behavior when
I wrote the new MIDI exporter.
That sounds right, but I only glanced at it momentarily.
The device file for the Yamaha MM6/MM8 was named MM6.rgd. I've just
copied it to a new file with a more helpful name. I don't think it
would be a good idea to delete the old file, though. I assume that
would break existing compositions that depend on it. Is there any sort
of policy for
On 09/03/2013 07:36 AM, D. Michael McIntyre wrote:
If you haven't had the pleasure yet, get ready. The new online API docs
really suck.
Being accomplished at navigating the old setup, I find this new setup a
horrible step backwards. It's a lot harder to find what I want, and
requires much
On 09/02/2013 03:52 AM, D. Michael McIntyre wrote:
We need EXTENSIVE!!! testing before releasing like this.
That would be nice. However, since it has no effect on a non-debug
build, it's not that big of a deal. Disabling it completely is simply a
matter of commenting out the setenv()
On 09/02/2013 08:12 AM, D. Michael McIntyre wrote:
1. create segment
2. right click - Transpose by Interval
QPainter::setPen: Painter not active
Completely reproducible. That's a good sign. I have to admit that
Transpose by Interval was one of the menu items that I didn't try.
Figures.
On 09/02/2013 08:54 AM, Ted Felix wrote:
On 09/02/2013 08:12 AM, D. Michael McIntyre wrote:
1. create segment
2. right click - Transpose by Interval
The issue is in NotePixmapFactory::makePitchDisplayPixmap(). It is
trying to make some bitmaps and whatnot, but it isn't properly setting
On 09/02/2013 09:47 AM, Niek van den Berg wrote:
Object::connect: No such signal
Rosegarden::GeneralConfigurationPage::updateSidebarStyle(unsigned int) in
src/gui/dialogs/ConfigureDialog.cpp:65
Just open the Preferences dialog, Rosegarden crashes.
Yes, thanks. I'll have a look. So far
On 09/02/2013 10:21 AM, Niek van den Berg wrote:
Another one:
1) Start Rosegarden
2) Create a segment
3) Open the segment in the Notation Editor
4) Notation Editor - Tools - Guitar Chord (or F9)
Thanks. I've fixed the last one. I'll give this one a shot in a
few. Keep 'em coming...
On 08/31/2013 07:45 AM, Yves Guillemot wrote:
I got the first Qt warnings crash : settings.endGroup() without beginGroup
when opening a RG file.
It's now fixed in r13383.
Thanks. I knew there would be more hiding in there.
Ted.
On 08/29/2013 06:18 AM, D. Michael McIntyre wrote:
Worst-case, when I'm done, you translation experts can just
right-click in the composition view and see how badly I've messed this up.
If what you mean by composition view is what I mean by segment
canvas then I think we're good.
On 08/29/2013 12:53 PM, Tom Breton (Tehom) wrote:
Seeing the next patch reminded me of the obvious answer: A distinct action
name (say, edit_paste_controllers) whose action is set to the same slot
as edit_paste.
That sounds good to me. Seems simple and clear.
Ted.
I'm in the middle of some code-shuffling to try and clear up the
final set of Qt warnings and I'm having to mess with menu items. These
are stored in the .rc files in data/rc. What I've had to do is create a
new segmenttool.rc file and it has entries like this:
Action name=edit_matrix
To celebrate our new level of quality, I highly recommend that
everyone grab the latest svn, fire up a debug build, bring up your
favorite editors, and go through your favorite menu items. If I've
missed any of the Qt warnings, this might cause a crash. If you make it
through this test
On 08/26/2013 12:38 PM, Tom Breton (Tehom) wrote:
It was running like 5-6% instead of 80-90%. That's a HUGE improvement
I never really appreciated until just now.
FWIW, Ted.
Yes. Good work, Ted!
Thanks guys. There should be more to come. Nothing quite as
dramatic, but certainly
On 08/23/2013 09:29 AM, D. Michael McIntyre wrote:
Next go round, we'll have an actual plan.
I think the confusion is just due to having two pages that appear to
be for the next release. How about just a single next version page.
Maybe it will gain a version number as we draw nearer to a
. Here's the patch in case anyone needs
it immediately:
commit 903271fb387ad4cc630c29810eecaacfb3e21080
Author: Ted Felix t...@tedfelix.com
Date: Wed Aug 14 19:02:33 2013 -0400
Increase MAX_CONNECTIONS to 100
This is an interim fix for Debian 719659.
diff --git a/connection_list.c b
The full fix for this is now available in the git repo on sourceforge.
http://sourceforge.net/projects/acpid2/
It now expands the connection list in increments of 20 connections as
needed up to 1024. add_connection() also has better error handling, so
problems in there will now be
On 08/01/2013 12:53 PM, Tom Breton (Tehom) wrote:
It might (just my educated guess) make sense to make it a segment observer
and augment the segment observer interface with efficient group
operations, and make Segment use those when it can. When I did that, it
was easy and worked well.
On 08/01/2013 01:44 PM, Tom Breton (Tehom) wrote:
I have reservations about trying to recover when NDEBUG isn't defined.
Ok, double-negative. Let me process that for a moment. NDEBUG not
defined means we are in... Um DEBUG mode! (Did I get that right?)
So you are saying that we
On 07/21/2013 09:55 AM, D. Michael McIntyre wrote:
http://www.youtube.com/watch?v=p9H-p_6OJPo
That was inspirational to say the least.
I think we need a video link collection on the wiki.
Ted.
--
See everything
On 07/20/2013 07:19 PM, Tom Breton (Tehom) wrote:
It's a case that (now) shouldn't be logically possible. IMHO it's better
for a failure of this logic to be an immediately obvious failure, but I
will of course conform to team standards.
I'm not sure what those standards are, so don't
On 07/06/2013 08:08 PM, Tom Breton (Tehom) wrote:
-#ifndef _RG_TRACKEDITOR_H_
-#define _RG_TRACKEDITOR_H_
+#ifndef RG_TRACKEDITOR_H
+#define RG_TRACKEDITOR_H
If we're switching to that style, I'm going to change the templates to
accord with it.
Yeah, that was something that cppcheck
On 07/06/2013 08:39 PM, Tom Breton (Tehom) wrote:
... and I just realized why. RG doesn't use the make clean system, it
treats every .cpp file as indicating an object file to be made and linked
in. You have to actually delete CompositionView.cpp if you don't want it
in the mix.
Do you
On 07/06/2013 09:19 PM, Tom Breton (Tehom) wrote:
OK, that still leaves you with the `find' errors in CompositionView.
Seems to be a failed template instantiation.
src/gui/editors/segment/compositionview/CompositionView.cpp:1432:96:
error: no matching function for call to
On 07/06/2013 09:58 PM, Ted Felix wrote:
However. I do believe that with one of my cleanups, I removed a
#include for algorithm:
#include algorithm
I just committed the fix for this as I believe this is indeed what is
causing Tom's build to fail. Hopefully this will give us a clean
Just wanted to see if there are any objections to something I'm
considering doing next week...
CompositionModel is an abstract interface class. However, there is
only one class that implements the interface, CompositionModelImpl. To
me, an abstract class with only a single deriver is
On 07/04/2013 07:13 AM, D. Michael McIntyre wrote:
A whole bunch of menu entries need to be policed for style. We have a
mix of Some menu item thing here and Some Menu Item Thing Here all
on the same menus.
I'd never noticed this. Thunderbird has the same problem. Chromium
and
On 07/02/2013 07:12 AM, Ted Felix wrote:
The customary way to handle this situation is as follows:
void f(int i)
{
#ifdef DEBUG_SEQUENCE_MANAGER
RG_DEBUG i;
#else
i; // suppress compiler warning
#endif
// ...
}
Actually, I'm a little bit off
On 07/02/2013 12:07 AM, Tom Breton (Tehom) wrote:
* These spurious warnings happened because some arguments like file and
line were used just if DEBUG_SEQUENCE_MANAGER was defined. AFAICT,
it's either spurious warnings, something like this, something uglier, or
a non-trivial rewrite.
On 07/01/2013 03:07 PM, Tom Breton (Tehom) wrote:
Please tell me if there are any problems.
Appears to pass the Beethoven test. One stuck note, but that's
probably because I ran fluidsynth during the test and CPU was rather
scarce (one core was pegged). So, MIDI recording is as it was
On 07/01/2013 04:01 PM, Tom Breton (Tehom) wrote:
On 07/01/2013 03:07 PM, Tom Breton (Tehom) wrote:
Please tell me if there are any problems.
This feels odd to me:
// #define DEBUG_SEQUENCE_MANAGER 1
#if !defined DEBUG_SEQUENCE_MANAGER
#define NDEBUG 1
#endif
NDEBUG is used to change
On 06/11/2013 10:27 PM, Tom Breton (Tehom) wrote:
Segment::setStartTime was the main culprit. It used to erase and insert
every event, with full notifications, causing enormous redundant
recalculation. computeSegmentOrigin, computeSegmentRect, and
rebuildVoiceCaches were called a truly
On 05/31/2013 11:49 AM, Colin Fletcher wrote:
The Sustain controller is not useful for 'ramping' up or down. The
sustain 'pedal' is either up (values 0 thru 63), or down (values 64
through 127).
Some (expensive) keyboard controllers actually do send the position of
the sustain pedal as a
On 05/30/2013 01:50 PM, Tom Breton (Tehom) wrote:
* For Pitchbend, Vibrato
* For Expression and Volume, Tremolo
* For anything else, Low-frequency variation unless someone can suggest
a better term.
Modulation? Or good ol' LFO as you mentioned before? I really
haven't even looked
I just released acpid 2.0.19 in response to the elevation to
serious severity. It should fix the compilation issue.
Ted.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I just released acpid 2.0.19 in response to the elevation to
serious severity. It should fix the compilation issue.
Ted.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 05/28/2013 02:55 PM, Holger Marzen wrote:
I got 13262 and didn't find my group_latency_off_by_one_patch
Was there a decision not to include it? If yes is there a place for use
at your own risk-patches?
I believe that we decided not to include it until someone had time to
review it.
The recently committed r13261 should provide a significant
improvement in performance when recording MIDI. With this change, I was
finally able to successfully record Aere's Beethoven MIDI sequence with
Rosegarden.
There's still a lot of work to be done in the area of MIDI recording
On 05/16/2013 04:05 PM, Rui Pereira wrote:
I'm looking for a way of mapping one keyboard to multiple tracks, in a way
that allows me, at limit, to have a key per track.
I don't think that rosegarden allows this in it's current state, but I'm
not afraid to look under the hood, and I am
On 04/24/2013 04:21 AM, Marek Elias wrote:
Input Layer: Type: 1 Code: 28 Value: 0
That's the Enter key. Nothing to worry about.
Input Layer: Type: 1 Code: 248 Value: 1
This is KEY_MICMUTE. That can easily be added to acpid by adding
the following lines to input_layer.c:
On 04/24/2013 10:19 AM, Marek Elias wrote:
I did the changed you suggested and rebuilt the acpid package.
Now I can see the events and run scripts with it.
Great. Then I'll go ahead and add the lines to the official source.
It will appear in the next version. Since there haven't been any
On 04/24/2013 10:19 AM, Marek Elias wrote:
I did the changed you suggested and rebuilt the acpid package.
Now I can see the events and run scripts with it.
I just added this change to the official source. If you wouldn't
mind retesting with the official source, I'd appreciate it. You can
On 04/21/2013 06:53 PM, Aere Greenway wrote:
As I recall, from months ago, Ted (I think it was Ted) said something
about the note-on event of the subsequent note being sorted so it
inadvertently came before the note-off event of the prior note, which
would produce a zero-length note.
Notes
On 04/19/2013 11:28 AM, Holger Marzen wrote:
So I'd say that getPluginLatency() and the data structures are ok, but
we have an error in connections.begin(). Of course it should be fixed
there instead subtracting 1 after its invocation.
Unfortunately due to my lack of C++ know how I can't find
On 04/18/2013 05:35 PM, D. Michael McIntyre wrote:
On 04/18/2013 11:41 AM, Holger Marzen wrote:
pluginLatency +=
m_instrumentMixer-getPluginLatency((unsigned int) *
connections.begin() - 1);
and it looks like the bug has been gone.
Nah, trying to start iterating from before
On 04/18/2013 06:30 PM, D. Michael McIntyre wrote:
I'm only using my C++ for Dummies intuition, not any actual knowledge or
skill, but that's what it looks like to me.
Yeah, well, I'm not even looking at the code. I'm using the Force.
And so far it hasn't revealed the location of that
On 04/18/2013 09:35 PM, Aere Greenway wrote:
It surprises me to have this particular machine referred to as low-spec
hardware, though compared to most new machines, it could be considered
that.
Don't get me wrong. I love low-spec. It's the only way to go if you
want to write fast code.
On 04/14/2013 04:30 AM, richard.b...@ferventsoftware.com wrote:
recording is buggy at the moment in particular and it needs a lot more
testing.
MIDI recording in rg has issues related to CPU usage, so that might
either be the entire problem, or might be making matters worse. Bear
this in
On 03/06/2013 05:08 AM, Chris Cannam wrote:
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.
Good point. Hadn't thought of that. Still, a default in the
application settings for new documents would be
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
On 02/23/2013 08:43 AM, Julien Cristau wrote:
On Tue, Jan 29, 2013 at 16:41:59 +1000, Peter Hutterer wrote:
X.Org Bug 73227 http://bugs.freedesktop.org/show_bug.cgi?id=73227
Bug number looks like a typo? Maybe that was supposed to be
https://bugs.freedesktop.org/show_bug.cgi?id=55329
56523
801 - 900 of 1017 matches
Mail list logo
