> Is this one?
>
> http://www.sequencer.de/pix/roland/roland_D10.jpg
Yes, looks exactly like the one I am configuring.
> If it is anything like my RD-600 you don't need no bank numbers, since
> you probably only have 128 programs: 8x8 = 64 in what you call "bank
> A" and another 64 in "bank B". In fact according to the picture it
> seems you have 8 "banks" of 8 sounds in thingy A and another 8 banks
> of 8 in thingy B.
> You see, Roland banks and MIDI banks are different beasts. Your "bank
> B" sounds will most likely be available at MIDI programs 64 to 127,
> MIDI MSB=0, LSB=0. Check your manual.
That did the trick! "id=x" where x is in {64..127} invokes bank B in the D10 !
thanks!
When I find time I'll try the same thing with the Korg and report results.

On Saturday 27 February 2010, John Tomlinson wrote:
> It appears that my membership of the list has been cancelled. This has
> happened twice now. I can rejoin but it is annoying.
No, but I've been getting a lot of "Bounce Action Notification" messages from
SourceForge/MailMan over the last week or so, which is unusual in of itself.
Normally these things show up once in a blue moon, instead of in clusters.
It may be a SourceForge problem. I apologize for your inconvenience, but I
have little control over this sort of thing.
--
D. Michael McIntyre

--- On Sat, 2/27/10, jimmy <wg2002a@...> wrote:
> Modality of progress dialog window can be a huge pain,
> especially when it is hidden behind some other windows.
>
> May I suggest that having a global (static) "status line(s)
> object/buffer" to be updated by the task at hand, especially
> the important tasks like file save. Then all the
> windows (main window, track editor...) which already has a
> status line (at the bottom) would just get notified when the
> status line object/buffer changes and display it. Of
> course, keep it short, be mindful of 640x480 resolution too,
> especially on netbooks (I don't have one of those) or older
> laptops.
>
Oops, sent that one out too quickly.
Of course, the notification to the Rosegarden windows about status changes should be done via separate normal/background thread, not the main/active GUI thread. Using GUI thread priority may tie up the system which is what we want to avoid.
Jimmy

Modality of progress dialog window can be a huge pain, especially when it is hidden behind some other windows.
May I suggest that having a global (static) "status line(s) object/buffer" to be updated by the task at hand, especially the important tasks like file save. Then all the windows (main window, track editor...) which already has a status line (at the bottom) would just get notified when the status line object/buffer changes and display it. Of course, keep it short, be mindful of 640x480 resolution too, especially on netbooks (I don't have one of those) or older laptops.
Jimmy

> I have transcribed all the instrument name and imported them into an *.rgd file (using Roland D50 rgd as template, primarily). When I load this newly created bank, it shows up correctly in the Instrument Panel. But no matter which of the two banks I choose -- A or B -- the Roland plays stuff in its bank A. (When Bank B is select and one of its instruments, the Roland plays the Bank A instrument that numerically corresponds to the selected Bank B instrument)
Is this one?
http://www.sequencer.de/pix/roland/roland_D10.jpg
If it is anything like my RD-600 you don't need no bank numbers, since
you probably only have 128 programs: 8x8 = 64 in what you call "bank
A" and another 64 in "bank B". In fact according to the picture it
seems you have 8 "banks" of 8 sounds in thingy A and another 8 banks
of 8 in thingy B.
You see, Roland banks and MIDI banks are different beasts. Your "bank
B" sounds will most likely be available at MIDI programs 64 to 127,
MIDI MSB=0, LSB=0. Check your manual.
Those buttons are certainly handy to have when you play live, but can
be confusing when you use the keyboard as a sound module.
HTH,
L

I apologize ahead of time - my question is probably broader in scope than RG, but is RG-relevant.
Switching banks seems like an intuitive no-brainer, looking at the banks dialog as well as at the "Instrument Parameters" section in the left panel in main window. Or even at the XML syntax and values of the *.rgd files.
However, i've tried two keyboards thus far -- Korg X5D and the old Roland D10 -- and have not been able to send write signals to the second bank.
Most recently, with the Roland D10 :
I have transcribed all the instrument name and imported them into an *.rgd file (using Roland D50 rgd as template, primarily). When I load this newly created bank, it shows up correctly in the Instrument Panel. But no matter which of the two banks I choose -- A or B -- the Roland plays stuff in its bank A. (When Bank B is select and one of its instruments, the Roland plays the Bank A instrument that numerically corresponds to the selected Bank B instrument)
Here is what I have in the roland-D10.rgd:
<bank name="Bank-A" msb="0" lsb="0">
...
</bank>
and
<bank name="Bank-B" msb="1" lsb="0">
...
</bank>
Judging from the Roland's behavior, it seems the MSB value has no effect. If it does not, what does? How do I send writes to alternate banks?
Thanks!
a.

On Wednesday 24 February 2010, Mark Dammer wrote:
> I notice that the new zoom and pan area... takes up a lot of desktop space
> on the notation editor... Is there a way to remove or this area or make it
> smaller?
No. Not without hacking the source code anyway.
--
D. Michael McIntyre

I notice that the new zoom and pan area with the "Sonic Visualizer like"
scrollwheels takes up a lot of desktop space on the notation editor
screen. It even overlaps the staves in multi page layout on my screen.
Is there a way to remove or this area or make it smaller ?
thanks for any help, Mark

On Tuesday 23 February 2010, david wrote:
> I suspect a hunk of the performance problems lie in the
> still-being-refined QT4 ...
That and our use of the new Qt classes is still being refined too.
I got some reactions off-list, so I want to go on public record saying
"*painfully* slow" is a bit of a pessimistic exaggeration here.
I've found Rosegarden usable on my slowest machine, which is some kind of
single core P4 or Am64. It's just not nearly as responsive as it used to be
when I run it alongside Classic for contrast. Whenever I do that, it's kind
of depressing.
Depressing or not, there's no going back. It took two years to get this far.
--
D. Michael McIntyre

D. Michael McIntyre wrote:
> On Tuesday 23 February 2010, Andrew wrote:
>
>> While hardware upgrades are good and desired, "upgrade your hardware"
>> should not be a knee-jerk response to "the code is running a bit slow" or
>> "this feature slows things down"
>
> I don't think I ever chimed in on this line of discussion.
>
> As far as "upgrade your hardware" as a response... Thanks to user support, I
> am able to afford a pretty decent development box in spite of my low-paying
> day job. I've got a Core2 Quad running at 2.33 GHz with 8 GB of RAM.
>
> The new Rosegarden is often *painfully* slow on this machine. "Upgrade your
> hardware" isn't even a viable response to these problems. Upgrade it to WHAT,
> pray tell? So "upgrade your hardware" is just rubbish after a certain point.
That's scary. My fastest machine here is a Sempron 3000+, an efficient
but single-core processor running at 1.8GHz with 1GB of RAM. My main
music machines are running Celeron processors - one an old-style 2.8GHz
with 768MB RAM, the other a Celeron M at 1.5GHz with 2GB of RAM.
RG 1.7.x on both is quite usable, not slow at all. (It was slow when the
first machine only had 512MB of RAM, some of which was bad.)
> I'm not sure where I'd draw the baseline on this new Rosegarden. It's got to
> be higher than it used to be, because we'll never extract that much efficiency
> out of this codebase, but it shouldn't be higher than the line I'm sitting at
> now.
>
> What we can do about these performance problems, I really don't know off the
> top of my head. Unfortunately, it's going to take a lot of careful analysis,
> a lot of time, and it's going to be a gradual, incremental thing. We've
> already gotten all of the big gains I think we're likely to see, so it's a
> laborious whittling process from here.
I suspect a hunk of the performance problems lie in the
still-being-refined QT4 ...
--
David
gnome@...
authenticity, honesty, community

On Tuesday 23 February 2010, Andrew wrote:
> While hardware upgrades are good and desired, "upgrade your hardware"
> should not be a knee-jerk response to "the code is running a bit slow" or
> "this feature slows things down"
I don't think I ever chimed in on this line of discussion.
As far as "upgrade your hardware" as a response... Thanks to user support, I
am able to afford a pretty decent development box in spite of my low-paying
day job. I've got a Core2 Quad running at 2.33 GHz with 8 GB of RAM.
The new Rosegarden is often *painfully* slow on this machine. "Upgrade your
hardware" isn't even a viable response to these problems. Upgrade it to WHAT,
pray tell? So "upgrade your hardware" is just rubbish after a certain point.
I'm not sure where I'd draw the baseline on this new Rosegarden. It's got to
be higher than it used to be, because we'll never extract that much efficiency
out of this codebase, but it shouldn't be higher than the line I'm sitting at
now.
What we can do about these performance problems, I really don't know off the
top of my head. Unfortunately, it's going to take a lot of careful analysis,
a lot of time, and it's going to be a gradual, incremental thing. We've
already gotten all of the big gains I think we're likely to see, so it's a
laborious whittling process from here.
--
D. Michael McIntyre

Hello Chris,
Concerning:
> I recently tried to install the driver for a newish HP
> printer on an
> old, 800MHz / 256MB laptop with Windows XP. The
> driver installer
> stopped and complained that I didn't have enough RAM,
> because it
> wanted 256MB and could only find, for some reason,
> 254MB. "Upgrade
> your RAM", it said. (It also said it wouldn't go any
> further anyway
> because my screen only had 24-bit colour, and it needed
> 32-bit.
> Rii-iight.)
Everybody needs 32-bit color to print out black and white text documents.
Specs. are quite insane these days.
Sincerely,
Julie S.

On Tue, Feb 23, 2010 at 4:29 PM, Andrew <nospam@...> wrote:
> While hardware upgrades are good and desired, "upgrade your hardware" should not be a knee-jerk response to "the code is running a bit slow" or "this feature slows things down".
I recently tried to install the driver for a newish HP printer on an
old, 800MHz / 256MB laptop with Windows XP. The driver installer
stopped and complained that I didn't have enough RAM, because it
wanted 256MB and could only find, for some reason, 254MB. "Upgrade
your RAM", it said. (It also said it wouldn't go any further anyway
because my screen only had 24-bit colour, and it needed 32-bit.
Rii-iight.)
I never did manage to work out how to overrule it.
For what it's worth, I tend to agree that it's much nicer for a
progress dialog not to show up if the operation is only going to take
a second or so. Assuming I find the time to work on this (as I hope
to), I'll try to enforce that. Actually it's supposed to work that
way already, but you know how it is.
Chris

On Mon, Feb 22, 2010 at 09:56:08PM -1000, david wrote:
> Andrew wrote:
> >>> With my occasional-user hat on, I'd be more than happy to see
> >>> progress dialogs dropped for routine operations like file
> >>> loading,
> >> Well, I like progress indicators for routine operations. If the
> >> operation is done too quickly for the indicator to appear, fine.
> >
> > i think the above should be a critical factor in the decision
> >
> > in my observation, on a somewhat sluggish (low-RAM) P4,
>
> If you have a low amount of memory, combined with a video adapter that
> steals system memory (a problem with many on-board video adapters these
> days), the problem gets even worse. Boost the RAM.
While hardware upgrades are good and desired, "upgrade your hardware" should not be a knee-jerk response to "the code is running a bit slow" or "this feature slows things down". After all, code optimizing is a well-known pursuit. Also, optimization in the broader sense -- figuring out what is the optimal tradeoff among UI features and their performance impact.
> > the GUI
> > overhead of the Save progress bar is actually slowing things down.
> > The Saving dialogue lingers for like 2 seconds - a bit frustrating.
>
> Hmmm, I don't consider 2 seconds frustrating at all.
Depends on how often you do "Ctrl+S" - i tend to do that often
Plus, it's sort of a disruption of my reading of the screen. My impulse is to try to make it go away...
> > Plus it's in the middle of the screen, preventing me from making use
> > of the 2 seconds to look over my tracks and what not, or just
> > interfering with my ongoing observation of what's on the screen...
>
> Unless RG's file save routines are designed for doing background saves,
> I wouldn't WANT the main program window accessible during a save. Too
> much risk of scrambling something in the RG file!
You can make the main window inaccessible but still readable. Should be a fairly easy code change (can't something be invisible but still in focus/foreground? i think that was the basis of the menu glitch with first release of Thorn -- correct me if i'm wrong)
Or the save progress bar could be tucked away in some corner? or let the user configure where they want it, if visible at all...
And, once again, *IF* there's a GUI overhead, i think it would be helpful to turn them off optionally, to reduce that overhead. I thought it was wonderful that the new RG version now saved so well DURING playback and record.... (until the save progress bar appeared :-)
my two cents.

Andrew wrote:
>>> With my occasional-user hat on, I'd be more than happy to see
>>> progress dialogs dropped for routine operations like file
>>> loading,
>> Well, I like progress indicators for routine operations. If the
>> operation is done too quickly for the indicator to appear, fine.
>
> i think the above should be a critical factor in the decision
>
> in my observation, on a somewhat sluggish (low-RAM) P4,
If you have a low amount of memory, combined with a video adapter that
steals system memory (a problem with many on-board video adapters these
days), the problem gets even worse. Boost the RAM.
> the GUI
> overhead of the Save progress bar is actually slowing things down.
> The Saving dialogue lingers for like 2 seconds - a bit frustrating.
Hmmm, I don't consider 2 seconds frustrating at all.
> Plus it's in the middle of the screen, preventing me from making use
> of the 2 seconds to look over my tracks and what not, or just
> interfering with my ongoing observation of what's on the screen...
Unless RG's file save routines are designed for doing background saves,
I wouldn't WANT the main program window accessible during a save. Too
much risk of scrambling something in the RG file!
> Or perhaps I am TOTALLY wrong here about the GUI overhead? Perhaps
> that's exactly who long it takes to save a RG file?
Don't know about that, it probably depends on how complex the RG file is.
--
David
gnome@...
authenticity, honesty, community

On Mon, Feb 22, 2010 at 09:53:57PM +0100, Thorsten Alteholz wrote:
> On Mon, 22 Feb 2010, Andrew wrote:
> >Are you saying it is NOT doable then? Or pedagogically stepping aside for
> >the pupil to do it? :-)))
>
> Oh, I just wanted to tell you what went wrong with your solution and put
> everything in the correct order into the repository. It is in the trunk
> now and working like a charm.
yes, confirmed, for me too! yea! now one can do one hundred re-takes standing 12 feet away (or whatever your remote's IR range is)
>
> So what is the next problem? :-)
well, while we're still on this topic...
In terms of your idea of network LIRC, can you think of practical applications? Could the over-the-network controll, perhaps, be a free$ alternative to buying LIRC hardware? used by those with laptops and desktops with their production RG process, controlling from their laptops? Would there be a way, say, to send signals from a networked BlackBerry?... and how about bluetooth-lirc ? check this out: http://code.google.com/p/lirc-bluetooth/ (top googling hit for me just now)
I think one could also connect Perl + LIRC + festival to vocalize the commands (completely independent and outside RG or any other app)... (if festival can use JACK)... that might diminish the likelihood of an accidental "undo" followed by "record" or whatever... (by the way, in any case, i meant to mention this danger on the list... include the "undo" at your own risk, and take care not to sit on your remote! :-). And, of course, just because it's an option in RG, it doesn't have to be configured in ~/.lircrc (effectively suppressed)
Well, I was thinking that "open recent -> topmost file" might be a useful remote config. Then there's the invocation of all these dialogs..., the transport, i would think, for sure, notation editor, percussion matrix, etc., et.c, etc.
And can each dialogue be toggled open/close by the same .lircrc button (per dialog) ? or by some sort of special .lircrc syntax ?
there are much more experienced RG users in this group who can suggest stuff.
-----
OK, i discovered a RG-LIRC factoid:
Since LIRC signals don't require a particular RG window or the app itself to be in focus (you could even be on a desktop different from the one RG is on), you can have vkeybd in focus and start recording with your remote, and begin playing the vkeybd right away insteading of having to Alt+TAB it back after it disappears upon your clicking the "record" button (... for all those doing their next serious masterpiece with VKeybd :-)))

On Mon, Feb 22, 2010 at 07:34:47PM +0100, Thorsten Alteholz wrote:
>
>
> On Sun, 21 Feb 2010, Andrew wrote:
> > So, the failure seems to be with "LircCommander::commands[]", but I
> > cannot see (not surprisingly, with my near-zero knowledge of C/C++) why
> > my additions to the "LircCommander::commands[]" declaration list is
> > inadequate...
>
> you almost got it right.
> You added the new entries at the end of the LircCommander::commands[].
> Unfortunately the bsearch function needs presorted data ...
Are you saying it is NOT doable then? Or pedagogically stepping aside for the pupil to do it? :-)))
Looking at the bsearch function and surrounding context I am lost in that syntax
by all means, i don't want to burden the rest of the readers with a C/C++/Qt 101 ... trying to subscribe to the devel list now (long auto-response delay (?))
(although, i'm fine continuing this thread in this list ... perhaps we could finish it here, and then use devel for any subsequent code discussion? -- i'll comply whichever way)
thanks
andrew

On Sun, 21 Feb 2010, Andrew wrote:
> So, the failure seems to be with "LircCommander::commands[]", but I
> cannot see (not surprisingly, with my near-zero knowledge of C/C++) why
> my additions to the "LircCommander::commands[]" declaration list is
> inadequate...
you almost got it right.
You added the new entries at the end of the LircCommander::commands[].
Unfortunately the bsearch function needs presorted data ...
Thorsten

>
> > That said, it might be useful to add an "UNDO" and "REDO" and perhaps a
> > few other essentials to the config.
>
> As you seem to have some experience with lirc and RG, what are the other
> essentials you are missing?
not sure. I have made several attempts over the years to grab RG by the horns (a-hem, by the keyboards, really -- sorry, couldn't resist), but due to glitches on my end and one missing component or another, have not really graduated past "tinkerer" (hoping to finally change that this time soon).
> It seems to be easy to connect a button on the remote to any already
> available RG slot. So if I find that UNDO and REDO slot it should be no
> problem to add these ...
well, there are references to both "undo()" and "redo()" in
src/gui/application/TranzportClient.* files
so, I added undo and redo to all the listings of slots and signals within
src/gui/application/LircCommander.*
as well as my .lircrc, of course (with new config names "UNDO" and "REDO").
The source then compiled without errors, and LIRC continued to work but only with the original set of singals/slots, my two don't seem to work.... something undeclared somewhere? (but then the compiler would complain, right?)
----------------------
Regarding controls over the network: I do not see a dire, sine-qua-non need for such, but have a vague notion such a feature might yield interesting things, creative solutions... if the coding isn't tedious, i vot yes on it.
-----------------------------------
code changes, FWIW :
in file LircCommander.h:
signals:
<snip most of list>
void trackRecord();
void undo();
void redo();
--------------
enum commandCode {
<snip most of list>
cmd_trackRecord,
cmd_undo,
cmd_redo,
};
in file LircCommander.cpp:
LircCommander::LircCommander(LircClient *lirc, RosegardenMainWindow *rgGUIApp)
: QObject()
{
m_lirc = lirc;
m_rgGUIApp = rgGUIApp;
<skip most of items...>
connect(this, SIGNAL(trackRecord()),
m_rgGUIApp, SLOT(slotToggleRecordCurrentTrack()) );
connect(this, SIGNAL(undo()),
m_rgGUIApp, SLOT(undo()) );
connect(this, SIGNAL(redo()),
m_rgGUIApp, SLOT(redo()) );
}
------------------------
LircCommander::command LircCommander::commands[] =
{
<skip most of items>
{ "TRACK-RECORD", cmd_trackRecord },
{ "UNDO", cmd_undo },
{ "REDO", cmd_redo },
};
----------------------
if (res != NULL)
{
switch (res->code)
{
<skip most of items>
case cmd_trackRecord:
emit trackRecord();
break;
case cmd_undo:
emit undo();
break;
case cmd_redo:
emit redo();
break;
---------

> > With my occasional-user hat on, I'd be more than happy to see progress
> > dialogs dropped for routine operations like file loading,
>
> Well, I like progress indicators for routine operations. If the
> operation is done too quickly for the indicator to appear, fine.
i think the above should be a critical factor in the decision
in my observation, on a somewhat sluggish (low-RAM) P4, the GUI overhead of the Save progress bar is actually slowing things down. The Saving dialogue lingers for like 2 seconds - a bit frustrating. Plus it's in the middle of the screen, preventing me from making use of the 2 seconds to look over my tracks and what not, or just interfering with my ongoing observation of what's on the screen...
Or perhaps I am TOTALLY wrong here about the GUI overhead? Perhaps that's exactly who long it takes to save a RG file?
by the way, I suppose there's no way to make them optional in user preferences?

Hi guys.
so far I found the new rosegarden 10.02 pretty nice.
Improvements in many places and also a more intuitive
percussion editor imho.
thanks to the devs for their nice work.
One thing that bothers me however, is when you have an editor open
(notation, matrix or percussion), the visual UI gets really slow. sound
playback is still rocksolid, but the graphical UI becomes stuttery.
(progress bar jumps about once every 700ms instead of moving
continuously, when clicking to change notes i takes a short while to
have effect, etc)
I tried both the "fast" and "safe" graphical performance setting but
they give the same problem. the only difference i noticed is when you
zoom out a lot the "fast" setting gives a bit less accurate note
representations - which is not a problem for me - but the UI is still
laggy.
Also, when editing 32nd notes and such, the display is quite blurry for
me. (and zoomed in a lot, the fast/safe performance setting gives the
same result)
see: http://users.edpnet.be/dieter/rosegarden-10.02.png
I'm on a 32bit Arch linux system
Amd athlon 1850MHz
1GB ram
nvidia 5700 or something like that
kernel 2.6.32 (non realtime, i don't need realtime for editing midi
performances)
any tips on making the UI faster and making the notes more clear?
thanks,
Dieter

On Sat, 20 Feb 2010 23:14:38 -0500, D. Michael McIntyre wrote:
> On Saturday 20 February 2010, John Murphy wrote:
>
> > Some kind of dialog is essential for lengthy operations if only to offer
> > a way to cancel it.
>
> A fair point. Although our cancel buttons are notoriously broken for that
> matter.
They couldn't possibly be as bad as the non-existent cancel button on a
certain non-daw application I tried last night. I (try to) work with
large .wav files sometimes. I dropped a 1.3GB (2 hour) one into it and
luckily still had the file manager open and noticed the .peak file as
it grew. Thought I'd better close it by the time it reached 10GB, but
it didn't close immediately and even when it did - the file still grew.
Had to find and manually kill the errant process. 14GB peak file anyone :)
--
John.