notice of works in progress...

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

notice of works in progress...

dmmcintyr (Bugzilla)
I just wanted to let everyone know that I sat down to do something about the
obnoxious audio file management issues that have been pissing me off for
awhile now.  (To wit, my 2 GB ~/rosegarden directory that I have no
reasonable way to make any sense of, and various project-specific directories
that are full of good files and bad alike.)

I don't have the time to actually build the code I just wrote just yet, and
I'm going to leave it sitting until I'm on the far side of all this book
stuff, and can go back to playing with HEAD.  I just wanted to get it down
while I was thinking about it.

I thought I'd make my intentions known in case anyone gets a wild hare up his
ass to tinker with this in the next couple of weeks.  I posted some design
discussion thing awhile back, which was ignored completely, so I'm just going
to go do what I think it needs, commit it, and see how it flies.

I'm probably going to mangle the SPB/IPB and some other things too, as per
another design discussion thing that was ignored completely.  It's just too
damn big, and we need to tighten it up and make more room for the segment
canvas.  Maybe I can dick with this in another branch and get opinions before
merging it into HEAD.  It's going to be a pretty sweeping change visually,
but I feel like it really needs to be done.  The segment canvas doesn't even
get half of my screen, and 1024x768 is still a lot more common than any other
resolution.

In fact, I think that's just what should be done.  I'll make a branch (can I
actually make a branch?  I guess so...) and then dick around with different
ideas for ways to tighten everything up without making it all look like
complete crap.  (Blender as an example of something that looks like complete
crap.  400 little meaningless icons, and no idea WTF any of them do.)  I have
at least two major streams of thought to play with, and I won't really know
what it looks like until I see it in the flesh.  I ultimately want to get
everything to the left of the actual segment canvas itself down to no more
than 1/3 of a 1024x768 screen, instead of about 56% of it.

--
Michael McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/
http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: notice of works in progress...

Chris Cannam
On Thursday 12 May 2005 07:00, Silvan wrote:
> I just wanted to let everyone know that I sat down to do something
> about the obnoxious audio file management issues that have been
> pissing me off for awhile now.

But what?  Your last email mentioned a number of problems, but I don't
recall that you were proposing any particular solution.

> In fact, I think that's just what should be done.  I'll make a branch
> (can I actually make a branch?  I guess so...)

Yes.

cvs tag -b branch_name
cvs update -r branch_name
cvs commit

You can do this before you start hacking away, or you can do it
immediately before you commit (i.e. you don't have to decide to create
the branch until you're about to commit to it -- it branches off the
last revision you updated from, so there's no problem if the repository
has changed in the mean time).


Chris


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: notice of works in progress...

dmmcintyr (Bugzilla)
On Friday 13 May 2005 06:56 pm, Chris Cannam wrote:

> > about the obnoxious audio file management issues that have been
> > pissing me off for awhile now.

> But what?  Your last email mentioned a number of problems, but I don't
> recall that you were proposing any particular solution.

"Toward the second end, we really need some
kind of morning after built in.  I would see this as something in the file
manager to delete all unused files.  Implementing the option itself is not
such a difficult proposition, but it could be a *dangerous* feature if the
user has not had discipline enough to keep this project's files isolated."

That's what I have under way.  Edit -> Unload and Delete Unused Files or
something to that effect.  It's not a bad solution.  The file manager knows
which files in ~/foo are associated with this particular project, so it won't
delete files from some other project unless the user has done something
external to Rosegarden to cause the names to be recycled somehow.  It needs  
big warnings, and I have it separate from the "Unload Unused Files" option to
keep it conceptually separate in users' minds.

"I feel that if we are to have a morning after function, we should make
compartmentalization mandatory, rather than an emphatic suggestion. "

I still agree with my original position, but I can't figure out how to make it
work, for the reasons surmised in the original message.  Renaming things is a
real problem.  It also causes problems for Plan B, which was to build the
composition name into the RG-AUDIO name in similar fashion to the autosave
files.

So, for various reasons, I think everything beyond this built-in morning after
pill is going to have to be done externally.

I've got a retrofit morning after pill in the book, in the form of
instructions for using a script that analyzes an .rg file, examines the audio
path, and determines which RG-AUDIO* files are not needed any longer.  (On
the presumption that if it has any other kind of name, it's not junk
automatically.)  This does NOT work unless the user has unloaded unused files
before saving the .rg, and it does NOT work if the user has files from more
than one project in the same place.  I have suitable disclaimers, and the
default action is to do nothing.  It's a crap solution, but it works.

The built-in version is better, because it is only aware of files that are
associated with the particular document that's loaded, so it's automatically
looking at a useful subset of whatever $AUDIO_PATH/ contains.  (It's
currently working except I haven't worked out how to actually delete the
files off the disk yet.)  Much less likely to cause collateral damage than my
retrofit script, although it's still not impossible.  Much less likely to
cause problems overall if people get used to using it as part of the last
stage of polishing off a composition.

When I get a chance, I want to expand this script into a $HOME-wide cleanup to
find ~ -name \*.rg and find ~ -name RG-AUDIO\*.wav and do appropriate things
comparing the two.  This is what I really need to fix my own mess regardless.  
If it isn't in use by a segment in any .rg file in my ~ then it's probably
cruft.

That's my thinking so far.  I haven't really had a hard think on it quite yet,
to see if I have any even better ideas.  I felt the morning after script I'm
putting with my book (putting on the SF web, with the URL in the book,
tutorial/rg-clean-audio if you're bored, although I'm not necessarily signing
off on this one as the final draft) was an essential thing to give to 1.0
users.  There just isn't any reasonable way in 1.0 to clean up the mess, even
if you have been polite enough to isolate your project's stuff to its own
unique place.

It's just a crappy bash script with pile of grep|cut|cut|cut stuff in it
though, and it's very delicate.

> the branch until you're about to commit to it -- it branches off the
> last revision you updated from, so there's no problem if the repository
> has changed in the mean time).

Great, I'll do that once I get to the other side of the book thing and have
time to play with it.  I really hope to come up with something acceptable,
even though I have my own doubts about winding up anywhere good.  I like
everything about the main window UI except for the fact that it's just too
damn big.

--
Michael McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/
http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: notice of works in progress...

Chris Cannam
On Saturday 14 May 2005 04:10, Silvan wrote:
> "Toward the second end, we really need some
> kind of morning after built in.  I would see this as something in the
> file manager to delete all unused files.

A problem with this is that, if the user is trying to keep their project
nice and tidy, they may well have already "unloaded" their unused
files, in which case the audio manager will no longer know about them.

We would need to make "unload" just remove them to a separate temporary
list so that the user still had some visibility of files arising from
the project but not actually used in it any more.  (I describe that as
a workaround, obviously we'd need to be pretty rigorous about what
files "live" where.)

Incidentally, the project packager has a similar capability already --
if a file is listed in the audio file list but unused in any segment,
it will ask you whether you want to package it (default "no").  So you
can in principle package in one place and un-package elsewhere to do a
cleanup, especially as the packager also pulls in dependencies that are
not in the project directory yet.  It still has bugs (especially in
unpackage), some work & help needed.

> Renaming things is a real problem.

Yeah.  At least putting the recorded date in the filename would be a
start.


Chris


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

rethinking audio

dmmcintyr (Bugzilla)
On Saturday 14 May 2005 05:52 am, Chris Cannam wrote:

I've been thinking, and, I want to take a step back for a moment.  My thinking
up to this point has centered on trying to find a way to make the existing
mechanisms easier to manage.  When I use this, I wind up with a mess, and I'm
looking for tools to make it easier to manage the mess after the fact.  
Ultimately, however, I am coming to think that the key here is to avoid the
situation that results in a mess in the first place.

As a user, I forget about the relationship between audio segments and files on
disk.  I don't think to look in the file manager.  I forget it's there.  The
whole thing is just not natural or intuitive to me.  I see the file manager
as something I should use to add extra files to the project from external
sources, but I don't really think of it as a place where the stuff I've done
within Rosegarden itself should show up.  (I realize that it does, mind you,
but even realizing this I tend to forget day to day.  I have to keep
reminding myself.)

What I feel should be the ideal state of affairs is for all segments to behave
the same way.  If I record a MIDI segment, I don't like it, I hit undo, and
it's gone.  I can redo to get it back.  If I delete a MIDI segment, then it's
gone.  I can undo to get it back.  I understand that if I undo to three
commands back, then do something unrelated, I have now cut myself off from
being able to redo actions that are no longer on the stack.  All of this is
perfectly intuitive and understandable, and that's the way everything works.  
If I back arrow my web browser to three URLs ago, then click a different
link, I've cut myself off from forward arrowing back to where I was a few
moments ago.  Same thing in a word processor, image editor, or any other
modern application I can think of.

So I think audio segments that are associated with audio files that Rosegarden
itself created should be treated just the same way as MIDI.  Audio data is
not inherently any more or any less precious to me than MIDI.  It should not
stick around forever in case I might want some last ditch way to undo a
grievous screw-up.  If I were to perform a similarly grievous screw-up with
MIDI data, it would be gone forever.  Undo/redo are there so you can take a
step back from a goof, but it only works if you catch it in time. That's
life, and that's the way everything else works.  Why should audio be
different?

So let's start the discussion from that question.  Why should audio be
different?  What is wrong with the following scenarios?  What am I not
thinking of?

a) I record an audio segment.  A file X gets created on disk.  I don't like
the recording.  I hit undo.  The file gets flagged for deletion.  I hit redo,
the segment comes back, and the file is no longer flagged for deletion.

b) I record another audio segment.  A file Y gets created on disk.  I hit undo
twice.  Now both files X and Y are flagged for deletion.  I hit redo, get
back file X.  File Y is still flagged for deletion.  Now I record a third
audio segment.  File Y is overwritten with the new recording.  Its original
contents are permanently gone.

I don't have time to sit here and think the rest of this out right now.  It
gets complicated when you copy segments or cut them up.  I think there is
more to sort out, but I think the overall idea is workable, and could be
implemented.  At the end of the session, anything that is still flagged for
deletion would be erased, just like any undone/deleted MIDI segments on the
stack would be erased from RAM at that point.

I'd love to bounce this line of thought back and forth and see if we can come
up with something agreeable.  The other ideas I've had for putting a bandaid
on the whole situation are less preferable in my mind than simply making
audio behave in the same fashion everything else does in the first place.  
Solve the problem at its root.  If these files were little .mid files full of
MIDI data instead, the whole situation as it stands today would be pretty
questionable, I think.

Thoughts?  Good idea, bad idea, I'm completely full of shit?

> Incidentally, the project packager has a similar capability already --
> if a file is listed in the audio file list but unused in any segment,
[...]
> not in the project directory yet.  It still has bugs (especially in
> unpackage), some work & help needed.

It's worth thinking about as a bandaid, but I don't see the packager as a
primary solution for the fundamental problem.  Not unless we utterly fail to
come up with any better ideas.

It does need testing though, and it is a very useful thing.  I intend to have
a good play with it, and send you that small test project I promised umpty
weeks ago.

--
Michael McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/
http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: rethinking audio

Chris Cannam
On Saturday 14 May 2005 22:23, Silvan wrote:
> So let's start the discussion from that question.  Why should audio
> be different?  What is wrong with the following scenarios?  What am I
> not thinking of?

Well, my gut feeling is that it's not a good idea to disregard the fact
that audio really _is_ different, because it involves separate and
potentially very large files on disc.  Also, they're more often (than
MIDI segments) the results of a specific take made in real-time that
might not be so easily repeatable.  This means, for example, that we
don't want to risk doing anything that will simply remove a file if
there's the slightest chance we may be mistaken.  Similarly, we want
the user to have enough personal control to feel like they can make
decisions about which files to keep and which to remove, from the
perspective of e.g. avoiding running out of disc space.

I would feel more comfortable about having the sequencer manage audio
files silently in this way if there was a stronger connection between
the audio files and the composition file -- for example, if the
composition was a tar file containing all its audio files (as a
Rosegarden project file is -- but I think this is not the most
practical thing for general load/save use) or if the user was expected
not to mess around with audio files themselves, instead leaving them at
Rosegarden's whim, in a project directory that Rosegarden created and
named (as is the case for e.g. Ardour -- almost certainly a better
scheme for audio projects, but it would be a right pain for plain MIDI
and notation compositions).

> a) I record an audio segment.  A file X gets created on disk.  I
> don't like the recording.  I hit undo.  The file gets flagged for
> deletion.  I hit redo, the segment comes back, and the file is no
> longer flagged for deletion.

OK, problem 1: you can't keep deleting and re-recording takes because
you'll run out of disc space because the files aren't actually being
deleted.  You need the manual control to be able to say you definitely
want to get rid of something.

You can say "well, when you record something new it can safely reuse
file X because you've undone the original recording and when you do
something new you lose the capability of invoking a redo".  But that's
relying on a particular usage of yours -- i.e. you evidently seem
inclined to hit Undo to discard a new recording, whereas someone else
(e.g. me) would naturally select it and hit Delete.  Thus, Rosegarden
would not be able to reuse the deleted segment in case the delete was
later undone.

> [The project packager] does need testing though, and it is a very
> useful thing.  I intend to have a good play with it, and send you that
> small test project I promised umpty weeks ago.

You'll notice it's now integrated into the Rosegarden tree (File ->
Export -> Export Rosegarden Project file...).

The main bug at the moment that I'm aware of is that it screws up when
you ask it to unpack to a .rg file with a different basename from that
of the .rgp file.  Not overwhelmingly hard to fix, just needs a few
spare minutes here and there...


Chris


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: rethinking audio

dmmcintyr (Bugzilla)
On Sunday 15 May 2005 05:46 am, you wrote:

> Well, my gut feeling is that it's not a good idea to disregard the fact
> that audio really _is_ different, because it involves separate and
> potentially very large files on disc.  Also, they're more often (than
> MIDI segments) the results of a specific take made in real-time that
> might not be so easily repeatable.

I'm not sure I agree.  Losing a 10 minute MIDI improv is no less tragic than
losing a really nice jam session.  You can argue questions of scale, of one
performance lost vs. several being lost simultaneously, but both ideas still
come down to the same idea of losing something ephemeral forever.  I wouldn't
lose the MIDI improv because I wouldn't delete it.  Why would I lose the
audio?  

> This means, for example, that we
> don't want to risk doing anything that will simply remove a file if
> there's the slightest chance we may be mistaken.  Similarly, we want
> the user to have enough personal control to feel like they can make
> decisions about which files to keep and which to remove, from the
> perspective of e.g. avoiding running out of disc space.

I would feel I had all the control in the world in the scenario I started to
outline.  Don't delete it, and it isn't deleted.  If we assume users can be
trusted to make their own decisions as to what should and should not be
deleted, where's the problem WRT their personal control?

The only problem I can see is if we get it wrong and delete things that they
didn't intend to delete.  There is room to err down that road, but it could
be sorted out so that they are no more and no less likely to cause a mishap
with audio than any other kind of data.

> I would feel more comfortable about having the sequencer manage audio
> files silently in this way if there was a stronger connection between
> the audio files and the composition file -- for example, if the

I agree.  It's probably an inescapable aspect of getting this whole scenerio
to go.  It has to be some piece of territory that RG controls exclusively.  
The composition "owns" the files somehow, perhaps in a hidden directory that
RG creates, and if you want to get them out to something else, you'd have to
export them out of RG's domain using some internal mechanism for that
purpose.  If you tried to circumvent this and do it by hand, we couldn't be
held responsible for the consequences.

Maybe one mechanism to export a particular file or files on demand from the
file manager, and another useful tool for the purpose could of course be the
project packager itself.  It's already necessary (well, very convenient
anyway) to use it if you want to share your composition with someone else, so
this need to "export" or "publish" the project via the packager to get all
the secret files into one place does not strike me as such a horror.

> OK, problem 1: you can't keep deleting and re-recording takes because
> you'll run out of disc space because the files aren't actually being
> deleted.  You need the manual control to be able to say you definitely
> want to get rid of something.
>
> You can say "well, when you record something new it can safely reuse
> file X because you've undone the original recording and when you do
> something new you lose the capability of invoking a redo".  But that's
> relying on a particular usage of yours -- i.e. you evidently seem
> inclined to hit Undo to discard a new recording, whereas someone else
> (e.g. me) would naturally select it and hit Delete.  Thus, Rosegarden
> would not be able to reuse the deleted segment in case the delete was
> later undone.

That's a very good point, and a big hole in my thinking.  RG couldn't record
over file Y immediately because of the need to be able to undo the deletion,
and so the space would add up.  At the end of the session, however, that need
goes away.  The space could be recovered by closing and re-opening the
document, which would flush out the undo stack, and go purge anything left
over that was still flagged for deletion.  It's a permanent act from which
there is no going back, but so is the equivalent act in MIDI terms.

Using the current mechanisms, if I ran out of disk space, I'd have to go
figure out what the files actually are and go delete them by hand, which
sucks.  I might quit RG, go package the file, unpack it somewhere sans cruft,
and re-start RG.  Being able to just cycle RG and flush the cruft without all
the intervening steps strikes me as much more convenient.  More convenient
than the "unload and delete unused" idea that I started this line of thought
with too.

Maybe even a "You're running out of space, do you want to flush the cruft?"
with suitable screaming disclaimers about destroying any data associated with
deleted audio segments permanently.

These problems could all be solved, I think.  It's a workable idea, if a
complicated one.  Is it worth it?  Is it better?  I think so, clearly, but it
would be good to hear other opinions.  Perhaps I'm the only user who detests
the current audio file management scheme so thoroughly.  I haven't heard
anyone else complain about it.  I love this idea, but I also see what a royal
PITA it would be to get it all working and sort out the many ways it could do
bad things.

> > [The project packager] does need testing though, and it is a very
> > useful thing.  I intend to have a good play with it, and send you that
> > small test project I promised umpty weeks ago.
>
> You'll notice it's now integrated into the Rosegarden tree (File ->
> Export -> Export Rosegarden Project file...).
>
> The main bug at the moment that I'm aware of is that it screws up when
> you ask it to unpack to a .rg file with a different basename from that
> of the .rgp file.  Not overwhelmingly hard to fix, just needs a few
> spare minutes here and there...

I'll have a play as soon as I figure out how to get CVS to build and install
again.

--
Michael McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/
http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: rethinking audio

Ross Vandegrift-2
On Sun, May 15, 2005 at 12:38:04PM -0400, Silvan wrote:
> Maybe even a "You're running out of space, do you want to flush the cruft?"
> with suitable screaming disclaimers about destroying any data associated with
> deleted audio segments permanently.

Ardour has a pretty great solution - basically, it implements both.

You can delete a region, but deleting a region doesn't delete any
audio files associated with it.  It simply orphans the audio.  This
lets you retrieve it if two days later you decided "hmm, that might
work here...".

You can also destroy a region.  This completely excises its existence.
The region is gone, the audio is gone, forever.  The software prompts
the user to make sure they understand the consequences of this action
with a dialog box.

Finally, there's an option to clear the cruft.  It basically goes
through and find orphaned sound files, and moves them to a
"dead_sounds" directory, which ardour or the user can clean out very
easily.

I have no idea how that maps onto RG since I've never used it for
audio, but the scheme is pretty sensible to me.  I've put a fair
number of hours behind various versions of ardour, and the ones from
before this file management cost me lots more in diskspace of dead
audio ::-).


--
Ross Vandegrift
[hidden email]

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
        --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: rethinking audio

dmmcintyr (Bugzilla)
On Sunday 15 May 2005 03:52 pm, [hidden email] wrote:

> Ardour has a pretty great solution - basically, it implements both.

Just so you don't feel ignored...

This gives us something to chew on, but I haven't had time to chew on it quite
yet, so think about how this overall idea could fit into RG's framework.  
It's definitely worth a think though.

--
Michael McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/
http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel