9 Apr
2004
9 Apr
'04
3:34 p.m.
Hello,
I was planning on starting a C++/GTKmm2-based multitracker project using
LADSPA and Jackit.
Before rolling on I would like to ask if there is already a project
planning on something similar.
Some existing C++ classes or gtkmm2 widgets could also be helpful.
Comments appreciated.
-Samuel
--
------------------------------------------------------
| Samuel Abels | http://www.debain.org |
| spam ad debain dod org | knipknap ad jabber dod org |
------------------------------------------------------
9 Apr
9 Apr
3:40 p.m.
On 04/09/04 15:30:32, Samuel Abels wrote:
Hello,
I was planning on starting a C++/GTKmm2-based multitracker project using
LADSPA and Jackit. Before rolling on I would like to ask if there is
already a project planning on something similar.
Gah, use Ardour. There is a need for a GTK2 midi sequencer though. *hint,
hint* :)
-Dave
4:08 p.m.
On Fri, 2004-04-09 at 21:37, Dave Robillard wrote:
On 04/09/04 15:30:32, Samuel Abels wrote:
As nice as Ardour may be, I personaly still prefer the interfaces of
modern UI toolkits, in combination with a nice Object Oriented language
(aka C++ :) ).
I was planning on starting a C++/GTKmm2-based
multitracker project using
LADSPA and Jackit. Before rolling on I would like to ask if there is
already a project planning on something similar.
Gah, use Ardour. There is a need for a GTK2 midi sequencer though.
*hint,
hint* :)
Actually, I have been thinking about that, also. Actually, I have even
created a (not completely finished) display widget for MIDI tracks using
GTK2-perl, which can be translated easily (=two hours work) into C++.
But, IMO that should be integrated with the multitrack application (as a
secondary feature).
-Samuel
--
------------------------------------------------------
| Samuel Abels | http://www.debain.org |
| spam ad debain dod org | knipknap ad jabber dod org |
------------------------------------------------------
4:25 p.m.
On Friday 09 April 2004 22:04, Samuel Abels wrote:
On Fri, 2004-04-09 at 21:37, Dave Robillard wrote:
If you want to write C++, why do you want GTK??? Use a C++-toolkit like Qt.
Arnold
--
Get my public-key from pgp.mit.edu or pgp.uni-mainz.de
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
On 04/09/04 15:30:32, Samuel Abels wrote:
As nice as Ardour may be, I personaly still prefer the interfaces of
modern UI toolkits, in combination with a nice Object Oriented language
(aka C++ :) ). I was planning on starting a C++/GTKmm2-based
multitracker project
using LADSPA and Jackit. Before rolling on I would like to ask if
there is already a project planning on something similar.
Gah, use Ardour.
4:56 p.m.
On Fri, 2004-04-09 at 22:18, Arnold Krille wrote:
Despite the fact that this is often discussed as a matter of religion, I
prefer gtkmm because it fits better into the GNOME environment.
Also, this is from the gtkmm-documentation:
http://www.murrayc.com/murray/talks/2002/GUADEC3/notes/html/index.html#id27…
"QT originates from a time when C++ was not standardised or well
supported by compilers. Its design today is still based upon the choices
available at that time, so it does not play well with more up-to-date
code. Development of QT is still effectively closed - There is still no
public development mailing list, and TrollTech have the normal corporate
conservatism. As an open-source project, its design would have been
improved through public debate, and it would have been possible to
jettison the baggage.
QT duplicates a lot of stuff that is now in the standard library, such
as containers and type information. Most significantly, they modified
the C++ language to provide signals, so that it's difficult to use QT
classes with non-QT classes. gtkmm was able to use standard C++ to
provide signals without changing the C++ language. And we use of
Standard C++ Library containers such as std::string, std::list,
std::vector and their iterators. We even provide STL-style interfaces to
other things such as container children, allowing you to use iterators
and push_back(), etc with these."
So, in essence, gtkmm does it in a more C++ way. :-) (But please let us
not make this a flame; may everyone be free to choose whatever toolkit
he likes best. ;) )
-Samuel
--
------------------------------------------------------
| Samuel Abels | http://www.debain.org |
| spam ad debain dod org | knipknap ad jabber dod org |
------------------------------------------------------
As nice as
Ardour may be, I personaly still prefer the interfaces of
modern UI toolkits, in combination with a nice Object Oriented language
(aka C++ :) ).
If you want to write C++, why do you want GTK??? Use a C++-toolkit like Qt. 
6:25 p.m.
This is from someone who uses both (including commercial Qt licenses at
work). I prefer Qt because it is more mature and documented better but
there's nothing wrong with GTK++. It shouldn't be a religious issue.
Try 'em both and pick the one you like the best and that fits your
background/style/objective the best.
Jan
On Fri, 2004-04-09 at 15:52, Samuel Abels wrote:
On Fri, 2004-04-09 at 22:18, Arnold Krille wrote:
Despite the fact that this is often discussed as a matter of religion, I
prefer gtkmm because it fits better into the GNOME environment.
Also, this is from the gtkmm-documentation:
http://www.murrayc.com/murray/talks/2002/GUADEC3/notes/html/index.html#id27…
"QT originates from a time when C++ was not standardised or well
supported by compilers. Its design today is still based upon the choices
available at that time, so it does not play well with more up-to-date
code. Development of QT is still effectively closed - There is still no
public development mailing list, and TrollTech have the normal corporate
conservatism. As an open-source project, its design would have been
improved through public debate, and it would have been possible to
jettison the baggage.
QT duplicates a lot of stuff that is now in the standard library, such
as containers and type information. Most significantly, they modified
the C++ language to provide signals, so that it's difficult to use QT
classes with non-QT classes. gtkmm was able to use standard C++ to
provide signals without changing the C++ language. And we use of
Standard C++ Library containers such as std::string, std::list,
std::vector and their iterators. We even provide STL-style interfaces to
other things such as container children, allowing you to use iterators
and push_back(), etc with these."
So, in essence, gtkmm does it in a more C++ way. :-) (But please let us
not make this a flame; may everyone be free to choose whatever toolkit
he likes best. ;) )
-Samuel
--
------------------------------------------------------
| Samuel Abels | http://www.debain.org |
| spam ad debain dod org | knipknap ad jabber dod org |
------------------------------------------------------
As nice
as Ardour may be, I personaly still prefer the interfaces of
modern UI toolkits, in combination with a nice Object Oriented language
(aka C++ :) ).
If you want to write C++, why do you want GTK??? Use a C++-toolkit like Qt. 
4:53 p.m.
On Fri, Apr 09, 2004 at 10:04:16PM +0200, Samuel Abels wrote:
One thing I'd love to have is *simple* MIDI sequencer that does *only* midi
(no audio whatsoever), is optimised to handle arbitrary note timing (no tempo,
beats, ...), and using the ALSA sequencer interface. The saved file format
doesn't even have to be midi. Sort of a dumb multitrack recorder for midi
data, slaved to JACK transport control.
Any candidates...
--
Fons
There is a
need for a GTK2 midi sequencer though. *hint,
hint* :)
Actually, I have been thinking about that, also. Actually, I have even
created a (not completely finished) display widget for MIDI tracks using
GTK2-perl, which can be translated easily (=two hours work) into C++.
8:21 p.m.
On 04/09/04 16:54:56, Fons Adriaensen wrote:
One thing I'd love to have is *simple* MIDI
sequencer that does *only* midi
(no audio whatsoever), is optimised to handle arbitrary note timing (no
tempo,
beats, ...), and using the ALSA sequencer interface. The saved file format
doesn't even have to be midi. Sort of a dumb multitrack recorder for midi
data, slaved to JACK transport control.
I agree completely that a straight plain MIDI sequencer is needed. Not so
sure about the no tempo idea though. Editing MIDI without the concept of
tempo and/or bars would be a most horrible thing. Ardour sync through some
means is definitely essential (and the thing that makes the current stable
version of MusE essentially useless to me). I don't know about "simple",
except the fact that it's just MIDI. I'd like a feature complete MIDI
sequencer (in gtk), not one that's sucked down feature-wise.
Writing a multitrack recorder is a duplication of effort - we already have one
(and I severely doubt anyone is going to be surpassing ardour in quality any
time soon).
We don't, however, have a just-MIDI sequencer, with all the nice features a
MIDI sequencer needs (like advanced control editing, etc.) The next version
of MuSe could be quite good, but it has all that audio stuff holding back
development, plus it's Qt of course..
(Random thought) A MIDI sequencer where you can draw control curves over the
tracks (like ardour volume and whatnot) would be very cool.. esp. for
electronic music (like, say, trance) when the control parameters are as
important as the notes themselves
-Dave
10:28 p.m.
On Fri, Apr 09, 2004 at 08:18:04PM -0400, Dave Robillard wrote:
On 04/09/04 16:54:56, Fons Adriaensen wrote:
What about seq24? It's simple and uses GTK. I think it also has
something where you can draw lines on a canvas to change control
parameters.
One thing I'd love to have is *simple* MIDI
sequencer that does *only* midi
(no audio whatsoever), is optimised to handle arbitrary note timing (no
tempo,
beats, ...), and using the ALSA sequencer interface. The saved file format
doesn't even have to be midi. Sort of a dumb multitrack recorder for midi
data, slaved to JACK transport control.
I agree completely that a straight plain MIDI sequencer is needed. Not so
sure about the no tempo idea though. Editing MIDI without the concept of
tempo and/or bars would be a most horrible thing. Ardour sync through some
means is definitely essential (and the thing that makes the current stable
version of MusE essentially useless to me). I don't know about "simple",
except the fact that it's just MIDI. I'd like a feature complete MIDI
sequencer (in gtk), not one that's sucked down feature-wise.
Writing a multitrack recorder is a duplication of effort - we already have
one (and I severely doubt anyone is going to be surpassing ardour in
quality any time soon).
We don't, however, have a just-MIDI sequencer, with all the nice features a
MIDI sequencer needs (like advanced control editing, etc.) The next
version of MuSe could be quite good, but it has all that audio stuff
holding back development, plus it's Qt of course..
(Random thought) A MIDI sequencer where you can draw control curves over
the tracks (like ardour volume and whatnot) would be very cool.. esp. for
electronic music (like, say, trance) when the control parameters are as
important as the notes themselves
-Dave
10 Apr
10 Apr
2:28 a.m.
On 04/09/04 18:25:00, will(a)malefactor.org wrote:
What about seq24? It's simple and uses GTK. I
think it also has
something where you can draw lines on a canvas to change control
parameters.
Seq24 is indeed very cool, I use it often and love it to death.
But a loop sequencer is something of a different beast than a "normal" track-
based (for lack of a better term...) sequencer.
-Dave
2:17 a.m.
On Saturday 10 April 2004 01:18, Dave Robillard wrote:
I agree completely that a straight plain MIDI
sequencer is needed. Not so
sure about the no tempo idea though. Editing MIDI without the concept of
tempo and/or bars would be a most horrible thing. Ardour sync through some
means is definitely essential (and the thing that makes the current stable
version of MusE essentially useless to me). I don't know about "simple",
except the fact that it's just MIDI. I'd like a feature complete MIDI
sequencer (in gtk), not one that's sucked down feature-wise.
Well if you can get over your gtk fixation then there's also Rosegarden of
course. Which offers JACK transport and hence "Ardour sync" (sic).
Writing a multitrack recorder is a duplication of
effort - we already have
one (and I severely doubt anyone is going to be surpassing ardour in
quality any time soon).
We don't, however, have a just-MIDI sequencer, with all the nice features a
MIDI sequencer needs (like advanced control editing, etc.) The next
version of MuSe could be quite good, but it has all that audio stuff
holding back development, plus it's Qt of course..
Well I don't know quite what to say here..
(Random thought) A MIDI sequencer where you can draw
control curves over
the tracks (like ardour volume and whatnot) would be very cool.. esp. for
electronic music (like, say, trance) when the control parameters are as
important as the notes themselves
Both MusE and Rosegarden support this.
The ideal is that just because MIDI data is simple, writing a MIDI sequencer
is somehow a trivial effort. You'd notice from the lack of contenders to
that crown that it evidently isn't. I'd suggest before anyone attempts to
reinvent the wheel that they fully understand what's trying to be
accomplished elsewhere and join forces.
Anyway, what about BEAST? That's gtkmm or GTK and does MIDI does it not?
It's amazing actually - I take a six month break from LAD after the peak of
those horrendous soft synth "architecture" discussions (whatever that acronym
was) and I find the same old (I'm afraid to say) ill-informed arguments
banging around. It reminds me of the USENET days. Death of the internet
predicted etc.
Do you think, just like the old USENET days, someone should write a LAD FAQ
and post it monthly? I think it'd greatly increase the clue quotient.
R
3:13 a.m.
On 04/10/04 02:10:43, Richard Bown wrote:
... are you sure about MusE? I can't find any reference to such a thing, or
find said feature myself (I do use MusE, if not very heavily). (Yes, MusE has
a control editor of some sort of course, but that's not what I'm talking
about). MusE /also/ has a bunch of audio stuff in the way.
Well if you can get over your gtk fixation then
there's also Rosegarden of
course. Which offers JACK transport and hence "Ardour sync" (sic).
Rosegarded depends on KDE. Don't get me wrong, I'm not militantly anti-qt (or
KDE, or anything without good reason), but I simply can't afford to be running
two desktop environments worth of crap at the same time, especially just for
one app. Plus Rosegarden has a bunch of audio stuff in the way.
Oh, and Ardour can sync via Jack transport, MTC, or MMC. Hence "Ardour sync
through some means". I'm sorry, I suppose I should have said "the
possibility
of syncronization with ardour utilising the appropriate technologies"?
(Random
thought) A MIDI sequencer where you can draw control curves over
the tracks (like ardour volume and whatnot) would be very cool.. esp. for
electronic music (like, say, trance) when the control parameters are as
important as the notes themselves
Both MusE and Rosegarden support this. The ideal is that just because MIDI data is simple,
writing a MIDI sequencer
is somehow a trivial effort. You'd notice from the lack of contenders to
that crown that it evidently isn't. I'd suggest before anyone attempts to
reinvent the wheel that they fully understand what's trying to be
accomplished elsewhere and join forces.
I fully understand that writing a MIDI sequencer is anything but a trivial
task. I don't know why you would assume otherwise, since I didn't say a
single thing even suggesting that was my 'ideal'.
Anyway, what about BEAST? That's gtkmm or GTK and
does MIDI does it not?
No alsa seq support AFAIK. Plus BEAST is pretty much the polar opposite of a
"pure" MIDI sequencer. (I'm beginning to think you didn't even read my
message)
Although tearing the MIDI sequencer stuff out of beast and adding alsa seq
support and jack sync wouldn't be a half bad idea...
It's amazing actually - I take a six month break
from LAD after the peak of
those horrendous soft synth "architecture" discussions (whatever that
acronym
was) and I find the same old (I'm afraid to say) ill-informed arguments
banging around. It reminds me of the USENET days. Death of the internet
predicted etc.
Do you think, just like the old USENET days, someone should write a LAD FAQ
and post it monthly? I think it'd greatly increase the clue quotient.
... Are you serious? The CLUE quotient? What, because I think a MIDI
sequencer that's simply focused on being a good MIDI sequencer is a good idea
I need a CLUE? (This coming from a guy who has taken a "six month break" from
LAD, and is impying that _I_ need to read a FAQ)
I'll keep my opinion of you and your comments to myself for obvious reasons.
I will however suggest trying to not be so blatently RUDE and INSULTING, and
maybe contributing something useful to the discussions at hand. (Not to
mention basing your comments on what people actually say instead of outlandish
assumptions on your part)
Anyway, since I apparently have to specifically ask for agruments or facts out
of you, instead of just ignorant uninformed bashing of my intelligence with no
justification, what exactly was ill-informed about my 'argument'?
-Dave (who is flat-out offended and throughly unimpressed at the moment)
3:49 a.m.
On Saturday 10 April 2004 08:09, Dave Robillard wrote:
Rosegarded depends on KDE. Don't get me wrong,
I'm not militantly anti-qt
(or KDE, or anything without good reason), but I simply can't afford to be
running two desktop environments worth of crap at the same time, especially
just for one app.
Well, it's just the kde-libs. Are you telling me you don't run any KDE apps
at the same time as your GNOME apps? I'm prepared to believe you don't but
I'd suggest that your hardware not being powerful enough to run both is a
pretty poor excuse for suggesting a whole new project.
Anyway, what's the problem with having audio stuff in a sequencer? If you
don't want to use it then don't - that's the beauty of it all isn't it?
Sounds like you haven't even tried it while deciding that Ardour is the only
solution. I agree that Ardour does audio really well, but it's not to
everyone's taste is it? Just as Protools isn't the only DAW that people use.
... Are you serious? The CLUE quotient? What,
because I think a MIDI
sequencer that's simply focused on being a good MIDI sequencer is a good
idea I need a CLUE? (This coming from a guy who has taken a "six month
break" from LAD, and is impying that _I_ need to read a FAQ)
Well like I said there isn't a FAQ but there should be.
I notice from the LAD list blurb:
"The linux-audio-dev list is unmoderated and open for everybody.
Note that the signal to noise ratio is extremely high on this list, and we
would like to keep it that way."
Harumph.
I'll keep my opinion of you and your comments to
myself for obvious
reasons. I will however suggest trying to not be so blatently RUDE and
INSULTING, and maybe contributing something useful to the discussions at
hand. (Not to mention basing your comments on what people actually say
instead of outlandish assumptions on your part)
I'm not insulting you - only your suggestion. I think your effort would be
better spent on the mailing lists of existing sequencer projects rather than
just suggesting another new one.
Anyway, since I apparently have to specifically ask
for agruments or facts
out of you, instead of just ignorant uninformed bashing of my intelligence
with no justification, what exactly was ill-informed about my 'argument'?
Sounds to me like you've not even tried what is out there already - you're
just waving your hand and saying "Oh, that's Qt/KDE", "Oh that has
audio"
etc. So what if it does? Do you not think your time would be better spent
improving what has come this far rather than starting _another_ project from
scratch? Have you seen the number of dead or stillborn projects on
Sourceforge? It takes years for these projects to mature - Rosegarden (the
project as a whole, not the latest incarnation) is 10 years old now. Do you
really think you're the first person to have these amazing ideas? Do you see
how I get bored of reading these recursive threads about how great it'd be if
only these things did this?
The main thing I'm suggesting here is that you or anyone else who wants to
start another sequencer project just help out with an existing one.
Personally I'd like you to tell us what Rosegarden _doesn't_ do for you -
slag it off, break it, complain about it. Just don't ignore it. If you've
got good reasons why it doesn't do what you want it to at a fundamental level
then fine - I've seen no such arguments from you yet.
I'm insulting you by telling you this and you're insulting me by ignoring all
the hard work that a lot of good people have already put in. If at the end
of the day you plain don't like it - fine - but at least give it a go.
R
7:33 a.m.
On Sat, Apr 10, 2004 at 08:41:58AM +0100, Richard Bown wrote:
[...]
Sounds to me like you've not even tried what is out there already - you're
[ranting deleted]
Do you not think your time would be better spent
improving what has come this far rather than starting _another_ project from
scratch? Have you seen the number of dead or stillborn projects on
Sourceforge? It takes years for these projects to mature - Rosegarden (the
project as a whole, not the latest incarnation) is 10 years old now. Do you
[ranting deleted]
The main thing I'm suggesting here is that you or anyone else who wants to
start another sequencer project just help out with an existing one.
Personally I'd like you to tell us what Rosegarden _doesn't_ do for you -
slag it off, break it, complain about it. Just don't ignore it. If you've
got good reasons why it doesn't do what you want it to at a fundamental level
then fine - I've seen no such arguments from you yet.
despite your rudeness you raise a very good point. I very much regret
that i have just started such a foolhardy endeavour. I have serious
doubts it will ever be finished, but i just couldnt find any existing projects
that were suitable. (I dont really want to announce it till i know its going to
work, but if any c(non++)/gtk2 programmers are interested in furthering the
unexplored ideas started by Logic, then pls contact me.
early screenshot: http://80.61.20.184/wiki/smgui_5.png)
its easy to say that you want criticism but its really not that easy.
Most people are not happy criticising other poeples work. Unless someone
knows you personally they are not going to know how you will respond. Perhaps
you are the same as me in that you thrive on criticism, but most people
are not like that. It is also time-consuming to prepare a proper criticism.
For me personally, Rosegarden is based on a simplistic outdated user interface
model, uses the wrong toolkit and wrong language, has spent too long on score
editing, and only has audio as an afterthought. Whenever i tried it i was
plagued with segfaults. There is no method listed on the webpage to submit
feedback to you without a subscription. In addition, the main developer is
regularly impolite, and not even humourously like the lovable MPlayer Arpi:-)
If you want feedback and/or greater community support then perhaps you should
consider encouraging it more, but hows that for starters?:-)
Please dont get me wrong, i have a great deal of respect for the Rosegarden
project - its just not suitable for me.
my feeling is that the only way round this continuing problem of fragmentation
is to use it to its advantage, via increased modularity. I would very much
be up for a discussion on how to facilitate that, as i havnt really been
able to come up with a satisfactory architecture myself and am stuck
re-implementing the same unpractical monolithic structure yet again with very
little code re-use. The problem i beleive is that while the code should be
modular, things have to be unified at the user interface level to make it
usable.
regards
--
Tim Orford
14 Apr
14 Apr
9:21 a.m.
Seems I missed a brief, pointless flamewar here. I've no interest in
re-lighting it, but I might as well reply to a couple of the concrete
points about Rosegarden, just for completeness. Don't anyone feel
obliged to reply to this, please.
On Saturday 10 Apr 2004 12:22 pm, Tim Orford wrote:
For me personally,
Rosegarden is based on a simplistic outdated user interface model
Rosegarden is a pretty traditional program, and deliberately so. Some
of the internals are capable of some damned clever stuff but the
focus in the GUI has always been to do a sensible range of basic,
useful stuff in a competent and comprehensible way rather than to do
any one thing spectacularly well. My apologies if that bores you,
but an application is only a tool after all -- exactly the same
description would apply to something like MusE, Ardour, Audacity etc.
Still, I've no problem with people insisting that Rosegarden is
unsuitable for them because they want an application with a more
particular focus than it has, rather than necessarily because of any
features it lacks. Looks like I disagree with Richard there.
uses the wrong toolkit and wrong language, has spent
too long on
score editing, and only has audio as an afterthought.
These are criticisms of the development of the software, rather than
of the software. None of those decisions is in itself relevant to a
user, only the visible results of those decisions.
Of course this is a developer's list, discussing software whose source
is available, so that sort of criticism is expected and reasonable,
especially in the context of whether one should help out in
developing a program or not. But consider how absurd it would sound
to criticise (say) Logic on the basis of the language and GUI toolkit
chosen to implement it. Why care?
I'm inclined to think that any time you look at a program and say
"well, it's a promising program but it's using the wrong language and
toolkit" you're probably just making a mistake in self-perception:
you think you're criticising one thing (the program), when in fact
you are only thinking about another (how you would have written the
program).
Whenever i
tried it i was plagued with segfaults.
Now that's where we like bug reports.
There is no method listed on
the webpage to submit feedback to you without a subscription.
You can post to rosegarden-devel and rosegarden-user without
subscription, although your posts will go through a moderator to
avoid spam, or you can enter bugs on the SourceForge tracker, which
we use very actively. (The latter is probably not made obvious
enough on the Rosegarden page.) It's all public; we don't encourage
anyone to submit bug reports privately.
In addition, the main developer is regularly impolite
Rosegarden has no main developer. It's had the same three core
developers for some years now, plus a handful of other developers
with CVS commit access, several active translators, and a body of
users whose views are taken very much into account. It's closer to
democratic than most Linux audio apps. Whether that's a good thing
is of course also open to question.
Chris
10 Apr
10 Apr
4:31 a.m.
Hi,
<...>
... are you sure about MusE? I can't find any reference to such a thing,
or find said feature myself (I do use MusE, if not very heavily). (Yes,
MusE has a control editor of some sort of course, but that's not what I'm
talking about).
Oh, then I must ask what the feature should do more explicitly? To my ears the
controller editor in MusE does exactly what you are asking for.
<...>
/R
(Random thought) A MIDI sequencer where you can draw
control curves
over the tracks (like ardour volume and whatnot) would be very cool..
esp. for electronic music (like, say, trance) when the control
parameters are as important as the notes themselves
Both MusE and Rosegarden support this.
12:57 p.m.
On 04/10/04 04:22:49, Robert Jonsson wrote:
Hi,
<...>
... are you sure about MusE? I can't find any reference to such a thing,
or find said feature myself (I do use MusE, if not very heavily). (Yes,
MusE has a control editor of some sort of course, but that's not what I'm
talking about).
Oh, then I must ask what the feature should do more explicitly? To my ears
the
controller editor in MusE does exactly what you are asking for.
Sorry, I wasn't really expecting discussion on that particular random thought
of the minute, so I didn't explain very well. :)
I was referring to seeing control curves drawn over top of the tracks in the
master track window. Something like this screenshot of sonar (best I could
find):
http://www.kvr-vst.com/i/b/sonar.jpg
It would be nice as you could see your entire piece from the main window, and
see where things evolve, how control changes relate to each other, etc.
The one (significantly more simple) feature I'd like to see in the MusE
control editor is a line-drawing option like seq24. Just load up seq24, plug
in a few notes and play with the control editor, you'll see what I mean.
It would be nice to hilight all my kick drums, then draw a nice line to set
all their velocities, for example.
-Dave
(Random thought) A MIDI sequencer where you can draw
control curves
over the tracks (like ardour volume and whatnot) would be very cool..
esp. for electronic music (like, say, trance) when the control
parameters are as important as the notes themselves
Both MusE and Rosegarden support this. 
3:28 p.m.
lördagen den 10 april 2004 18.53 skrev Dave Robillard:
Ahh, you are right, this is not possible (yet) in MusE, it's been up for
discussion though (I tend to refer to it as "automation" btw), I will add it
to the TODO.
On 04/10/04 04:22:49, Robert Jonsson wrote:
> Hi,
<...>
Oh, then I
must ask what the feature should do more explicitly? To my
ears the
controller editor in MusE does exactly what you are asking for.
Sorry, I wasn't really expecting discussion on that particular random
thought of the minute, so I didn't explain very well. :)
I was referring to seeing control curves drawn over top of the tracks in
the master track window. Something like this screenshot of sonar (best I
could find):
http://www.kvr-vst.com/i/b/sonar.jpg
It would be nice as you could see your entire piece from the main window,
and see where things evolve, how control changes relate to each other, etc.
The one (significantly more simple) feature I'd like to see in the MusE
control editor is a line-drawing option like seq24. Just load up seq24,
plug in a few notes and play with the control editor, you'll see what I
mean.
It would be nice to hilight all my kick drums, then draw a nice line to set
all their velocities, for example.
Ok, I didn't try but I think I understand what you mean, this will probably
come as a natural progression of the former feature .
For what it's worth it's possible to use the Pen tool to draw curves atleast,
if you got a stable hand you might be able to do pretty good lines to :)
/Robert
-Dave
19 Apr
19 Apr
6:24 a.m.
Hi again,
revisiting an old thread.
<...>
> It would be nice as you could see your entire
piece from the main window,
> and see where things evolve, how control changes relate to each other,
> etc.
>
> The one (significantly more simple) feature I'd like to see in the MusE
> control editor is a line-drawing option like seq24. Just load up seq24,
> plug in a few notes and play with the control editor, you'll see what I
> mean.
>
> It would be nice to hilight all my kick drums, then draw a nice line to
> set all their velocities, for example.
I found out that this infact is already possible in MusE, I'm not sure if it
works as seq24 (have not come around to try it), but the feature is there.
Highlight the kickdrum, draw a line, done.
/Robert
9 Apr
9 Apr
5:15 p.m.
On Fri, Apr 09, 2004 at 10:04:16PM +0200, Samuel Abels wrote:
On Fri, 2004-04-09 at 21:37, Dave Robillard wrote:
Ardour is going to move to GTK 2 sometime after 1.0.
Maybe you could help with that?
On 04/09/04 15:30:32, Samuel Abels wrote:
As nice as Ardour may be, I personaly still prefer the interfaces of
modern UI toolkits, I was planning on starting a C++/GTKmm2-based
multitracker project using
LADSPA and Jackit. Before rolling on I would like to ask if there is
already a project planning on something similar.
Gah, use Ardour. in combination with a nice Object Oriented language
(aka C++ :) ).
Ardour is written in C++.
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's MEGA-MEGATRON BAKER!
(random hero from isometric.spaceninja.com)
5:31 p.m.
Hallo,
Paul Winkler hat gesagt: // Paul Winkler wrote:
On Fri, Apr 09, 2004 at 10:04:16PM +0200, Samuel Abels
wrote:
And in a very nice and readable one, that is. Considering the size of
it.
Ciao
--
Frank Barknecht _ ______footils.org__
in combination with a nice Object Oriented
language
(aka C++ :) ).
Ardour is written in C++. 
5:16 p.m.
LADSPA and Jackit. Before rolling on I would like to
ask if there is
already a project planning on something similar.
Gah, use Ardour.
5:39 p.m.
I will follow up on ardour-devel.
On Fri, 2004-04-09 at 23:09, Paul Davis wrote:
As nice as Ardour may be, I personaly still prefer the interfaces of
modern UI toolkits, in combination with a nice Object Oriented language
(aka C++ :) ).
Just to be clear:
1) Ardour is written in C++
2) Ardour's toolkit is gtkmm
3) Ardour will be ported to GTK2/gtkmm immediately after we release v1.0
4) 90% of the hard stuff in a multitrack editor is inevitably
focused on a canvas-like widget, which will be filled
with custom items that are not provided by whatever
toolkit you choose.
5) Ardour has 100% separation between GUI and backend code.
--p --
------------------------------------------------------
| Samuel Abels | http://www.debain.org |
| spam ad debain dod org | knipknap ad jabber dod org |
------------------------------------------------------
LADSPA and
Jackit. Before rolling on I would like to ask if there is
already a project planning on something similar.
Gah, use Ardour. 
23 Apr
23 Apr
10:22 p.m.
Dave Robillard <drobilla(a)connect.carleton.ca> writes:
There is a need for a GTK2 midi sequencer though.
Take a look at beast, beast.gtk.org. It has a piano roll and the old style tracker
interface.
--
b0ef
http://users.resentment.org/b0ef
b0ef(a)resentment.org - (not in use for now)
#ofpe(a)irc.gnu.org
7314
days inactive
7328
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
14 participants
participants (14)
-
Arnold Krille -
Chris Cannam -
Dave Robillard -
Esben Stien -
Fons Adriaensen -
Frank Barknecht -
Jan Depner -
Paul Davis -
Paul Winkler -
Richard Bown -
Robert Jonsson -
Samuel Abels -
Tim Orford -
will＠malefactor.org