Rosegarden

On Monday 01 Mar 2004 11:33 am, Vladimir Savic wrote:
> When told rosegarden to use my soundfont, I have forgoten that
> if there is oss emulation loaded over alsa, sfxload cann't find
> /dev/sequencer.

I can't test it because I don't have an emu10k, but I imagine there 
could well be problems arising from the fact that sfxload is an OSS 
application and not an ALSA one.  I don't think that quite explains 
your particular problem there though.

There is now a program called "asfxload" which is the ALSA native 
equivalent.  It's pretty new though.  You can find it in the 0.5.0 
release of Takashi Iwai's awedrv package, from

http://www.alsa-project.org/~iwai/awedrv.html#Utils

Needless to say I haven't tested that either.


Chris

On Monday 01 March 2004 12:33, Vladimir Savic wrote:
>
> When told rosegarden to use my soundfont, I have forgoten that
> if there is oss emulation loaded over alsa, sfxload cann't find
> /dev/sequencer.
> Rosegarden started and after .rg file have been loaded (specified on
> comand line)
> rosegarden freezes. Must to "killall" it, and than to move physicaly sf2
> file to
> another location. Than RG started fine.

I've changed the way the process is handled, the UI shouldn't freeze anymore, 
but it's still possible that sfxload would hang. Can you please update and 
retry, and check that you have this message in the debug traces :

rosegarden: RosegardenApplication::sfxLoadExited() : sfxload exited normally

-- 
						Guillaume.
						http://www.telegraph-road.org

On Monday 01 March 2004 17:13, Vladimir Savic wrote:

> 2) In notation editor.. sliders for spacing and size must be draged, other
> way thay just knock into "min. /max." value position. This happens when
> left-click with mouse left or right from sliders current position. Middle
> button works fine!

Yes, I have this one too. It's quite peculiar, probably a signal being fed 
back to the widget.

-- 
						Guillaume.
						http://www.telegraph-road.org

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag 28 Februar 2004 15:02 schrieb Chris Cannam:
> On Saturday 28 Feb 2004 1:57 pm, Eckhard Jokisch wrote:
> > Or is someone working on a patch integrating it already?
>
> I'm not sure it will need any integration actually.  I think it just
> attempts to do the right thing with the server without any input from
> the application at all.
With integration I meant all the testing and removing of obsolete code.=20
Thinking that you have a lot more to do on topics where I can't help.

So I'll do it.
>
>
> Chris
Eckhard
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAQLXRiF9FD4kCbGQRAv1MAJ0dGFACi9CfIjNhNB6/N7OgSFpC2gCfemD1
SIJAApF0Onru28DTEvR1akE=3D
=3DXkzr
=2D----END PGP SIGNATURE-----

On Friday 27 February 2004 16:47, Chris Cannam wrote:

> There's a bug in the use of execv, so you'll probably need this:

Hmm, still no dice.  Even recompiled clients which I think I'm right in 
thinking I don't need to.

R

On Sunday 29 Feb 2004 6:01 pm, Hans Kieserman wrote:
> The specific problem I'm dealing with is loading a MIDI file with a
> large number of tracks, all of which use unavailable sounds

Hmm, so you've told Rosegarden about the configuration of your synth, 
but when you load your file it was designed for another synth and so 
the programs and banks are all coded to numbers that your synth 
doesn't support -- I can see that would be irritating, yes.

I've had other situations in the past in which it would be desirable 
to be able to change the program on more than one instrument at once: 
I quite often end up with multiple instruments set to the same 
program but on different channels.

Hm.


Chris

On Sunday 29 February 2004 01:35 pm, Chris Cannam wrote:

> Hmm, so you've told Rosegarden about the configuration of your synth,
> but when you load your file it was designed for another synth and so
> the programs and banks are all coded to numbers that your synth
> doesn't support -- I can see that would be irritating, yes.

Someone implemented it, or claimed to.  That was what the '[x] use default 
autoload" or whatever I called it option was supposed to be all about.  I 
configure my autoload to describe the hardware I actually have, and then if I 
load a file whose studio describes something completely different, it uses 
*my* studio.  That probably would still require me to dick around pointing 
tracks at instruments that actually exist though.  Also, I never really 
tested it, and I have no idea if the implementation (if there has been an 
implementation) works as I had in mind.

-- 
Michael McIntyre  ----   Silvan <dmmcintyr@...>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/

On Sunday 29 Feb 2004 9:20 pm, Silvan wrote:
> Someone implemented it, or claimed to.  That was what the '[x] use
> default autoload" or whatever I called it option was supposed to be
> all about.

Firstly: no, that isn't implemented yet.  You're thinking of the other 
options you added to the GUI at the same time, the "Import Default 
Studio" and "Import Studio from File..." options on the Studio menu, 
which I wired up a few months ago.  The configuration option itself 
has never been used for anything yet.

Secondly, isn't that a slightly different problem?  Or in fact, isn't 
that a situation in which Hans's problem is actually more likely to 
occur, not less?  If you think about it, each instrument has (well, 
optionally anyway) program and bank numbers associated with it, and 
they're just numbers -- the file records the number values regardless 
of whether the programs are actually configured in the studio or not.  
Load a file and then load a different studio over the top, and you 
make it even more likely that the numbers stored in the file will 
correspond with the wrong programs in the new studio, or worse, won't 
correspond with any existing programs at all.


Chris

On Saturday 28 February 2004 19:12, Hans Kieserman wrote:

> 1) selecting a track selects the corresponding segment, but not vice versa.
> should it?

Well you might get into a bit of bother with multiple selections, sweep 
selections etc.  It might make sense when just selecting a single segment 
though - that could be useful.

> 2) segment parameters don't update properly.  submitted a bug on this one.
> in progress.

Yep.

> 3) is there any way (theoretically) to ask the sequencer/system/etc. what
> soundfonts are actually available and default to ones that create sound,
> i.e. choose gm grand piano if viola isn't available?  or do we just have to
> push events to the synth and hope something happens?

The latter.  I don't think we should worry about soundfonts/soundfont loading 
at this stage at the RG level.  Like I mentioned, there is a proper solution 
in the pipeline sometime and we should probably just wait until then and 
document properly how to use softsynths and soundfonts rather than trying to 
code around it.

> 4) would it be a reasonable idea to provide default track settings for old
> RG files (where pan, etc. are missing) similar to those provided for new
> files?

Sounds good.

> 5) the "deprecated feature found in rg file, please re-save" messages can
> get quite overwhelming.  see doodle-q.  I'm hunting for the best way to
> provide this info- do we really need to report every event?  (we do only
> report one messagebox, but the console gets all of them)

Sounds like a worthwhile piece of work there too.

R

On Saturday 28 Feb 2004 7:12 pm, Hans Kieserman wrote:
> 5) the "deprecated feature found in rg file, please re-save"
> messages can get quite overwhelming.

Actually I think it was simply a mistake to dump that out for every 
one of the old-style controller elements.  I think I might prefer to 
revert that rather than only warning the first time.


Chris

On Sunday 29 February 2004 11:07, Richard Bown wrote:
> The latter. =C2=A0I don't think we should worry about soundfonts/soundf=
ont
> loading at this stage at the RG level.

Well, it seemed easy enough so I just added it. RG will now call sfxload =
with=20
the selected soundfont at startup. It's disabled by default, the options =
are=20
on the 'Sequencer' settings page.

--=20
						Guillaume.
						http://www.telegraph-road.org

On Sunday 29 February 2004 19:14, Guillaume Laurent wrote:
> On Sunday 29 February 2004 11:07, Richard Bown wrote:
> > The latter.  I don't think we should worry about soundfonts/soundfont
> > loading at this stage at the RG level.
>
> Well, it seemed easy enough so I just added it.

How easy it is to do isn't strictly the point but it's a useful feature 
nonetheless.

> RG will now call sfxload
> with the selected soundfont at startup. It's disabled by default, the
> options are on the 'Sequencer' settings page.

Fixed for KDE3.1.

R

On Saturday 28 February 2004 08:18 pm, Silvan wrote:
> Did a CVS update, then ran:
>
> ->sudo make uninstall&&make distclean&&./configure --prefix=/usr
> --enable-debug=full&&make&&sudo make install

I did forget to make Makefile.cvs...  I'm trying that now, just in case.

Before anyone points it out to me.

-- 
Michael McIntyre  ----   Silvan <dmmcintyr@...>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/

On Saturday 28 February 2004 08:29 pm, Silvan wrote:

> I did forget to make Makefile.cvs...  I'm trying that now, just in case.
>
> Before anyone points it out to me.

No change.

I still can't figure out why the hell I need libGL.so in the first place.

-- 
Michael McIntyre  ----   Silvan <dmmcintyr@...>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/

On Sunday 29 February 2004 05:03, Silvan wrote:
>
> I still can't figure out why the hell I need libGL.so in the first place.

A probable cause is that you've compiled Qt with OpenGL support in.

-- 
						Guillaume.
						http://www.telegraph-road.org

On Sunday 29 Feb 2004 7:43 am, Guillaume Laurent wrote:
> On Sunday 29 February 2004 05:03, Silvan wrote:
> > I still can't figure out why the hell I need libGL.so in the
> > first place.
>
> A probable cause is that you've compiled Qt with OpenGL support in.

I received a question about this (off-list) the other day, and it was 
quite a surprise to me too.  I suggested looking for a mesa-devel 
package and installing that, which apparently worked, but that's not 
an obvious fix at all if you haven't heard of the packages involved, 
so it's pretty much a brick wall for anyone just trying to install 
Rosegarden.


Chris

On Sunday 29 February 2004 08:49 am, Chris Cannam wrote:

> > > I still can't figure out why the hell I need libGL.so in the
> > > first place.
> >
> > A probable cause is that you've compiled Qt with OpenGL support in.
>
> I received a question about this (off-list) the other day, and it was
> quite a surprise to me too.  I suggested looking for a mesa-devel
> package and installing that, which apparently worked, but that's not
> an obvious fix at all if you haven't heard of the packages involved,
> so it's pretty much a brick wall for anyone just trying to install
> Rosegarden.

I should have resolved it correctly, but instead, I hacked it.  The hack 
(manually creating a libGL.so symlink that wasn't broken) got RG to compile, 
but now I have no idea which package broke what, so I can't be of any use to 
the Debian people in sorting out why this happened in the first place.

It was doubtless a broken install/remove script in a bad package.

This is where Rich bitches as me for tracking Testing instead of running 
something stable.

-- 
Michael McIntyre  ----   Silvan <dmmcintyr@...>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/