On Sunday 14 February 2016 21:57:33 Yves Guillemot wrote:
> The bug should be fixed in rev. 14518. (At least it's fixed on my system).
>
> Some objects related to audio files read and write are now explicitely in
> main.
>
> Previously they was defined as static and no more initialized when thei
The bug should be fixed in rev. 14518. (At least it's fixed on my system).
Some objects related to audio files read and write are now explicitely in main.
Previously they was defined as static and no more initialized when their code
was included in a static library.
This is why the bug was not
Glad I could help.
--- On Fri, 3/9/12, Aere Greenway wrote:
From: Aere Greenway
Subject: Re: [Rosegarden-devel] Question on running Rosegarden from inside a
Java program
To: "Julie S"
Cc: "Rosegarden Developers"
Date: Friday, March 9, 2012, 11:06 PM
Julie:
ts of stuff to standard output on startup. So if the
> stream is not getting drained, this will create blocking -- probably
> the blocking you are experiencing.
>
> Sincerely,
> Julie S.
>
> --- On Wed, 3/7/12, Aere Greenway wrote:
>
>
> From: Aere
of stuff to standard output on startup. So if the stream is not
getting drained, this will create blocking -- probably the blocking you are
experiencing.
Sincerely,
Julie S.
--- On Wed, 3/7/12, Aere Greenway wrote:
From: Aere Greenway
Subject: [Rosegarden-devel] Question on running
Rosegarden Developers:
I have been experimenting with running various Linux MIDI components
from within a Java program, and my experiments have been successful,
with one exception:
When I attempt to run rosegarden from within the Java program (using an
instance of the "Runtime" class, and its "e
On Sunday, February 05, 2012, Niek van den Berg wrote:
> It seemed both Peter and I are working on a MusicXML importer and want to
> combine our efforts.
Indeed.
> A simple question: What is the best way to do so. Starting a new branch?
> Make modifications in the main code base? Some other opti
Dear all
It seemed both Peter and I are working on a MusicXML importer and want to
combine our efforts.
A simple question: What is the best way to do so. Starting a new branch? Make
modifications in the main code base? Some other option?
Can somebody advise on this?
Best regards,
Niek van den
Hello Luis,
Thank you for the information, that confirms my understanding. Thank you for
the detailed explanation as well.
Typically, I just research this stuff myself instead of asking, but I was (at
the time) feeling pressed to get the bug fix out before re-release...but that
turns out to n
On Mon, Feb 7, 2011 at 12:28 AM, D. Michael McIntyre
wrote:
> On Sunday, February 06, 2011, Julie S wrote:
>
>> Since "this" is inherits from QGroupBox in this case, it appears Qt will
>> take care of the details of deleting the QTimer.
>
> I think that's probably right. I'm not 100% sure myself.
On Sunday, February 06, 2011, Julie S wrote:
> Since "this" is inherits from QGroupBox in this case, it appears Qt will
> take care of the details of deleting the QTimer.
I think that's probably right. I'm not 100% sure myself.
--
D. Michael McIntyre
---
Hello All,
Concerning my question:
> Is this true for QTimer as well? In my case I'm
> passing I'm doing this:
>
> m_delayUpdateTimer = new QTimer(this);
>
Since "this" is inherits from QGroupBox in this case, it appears Qt will take
care of the details of deleting the QTimer.
If this is inc
Hello All,
I know that typically when we use Qt and create GUI items like buttons, check
boxes, etc. We don't explicitly use "delete" on them in a Classes destructor.
Is this true for QTimer as well? In my case I'm passing I'm doing this:
m_delayUpdateTimer = new QTimer(this);
So will Qt han
On Tuesday 02 February 2010, Brian Clem wrote:
> 2. I am wondering if my next step will involve troubleshooting on my
> end or temporally installing Classic. Here is my issue: I CAN route
> my midi tracks to Fluidsynth through externally loaded Qsynth. I
> would rather load Fluidsynth for each
Hello,
1. I just loaded 10.02 and was very impressed with the quick response
when loading Fluidsynth DSSI and the .sf2's. Now THAT is exciting.
The performance boost is greatly appreciated.
2. I am wondering if my next step will involve troubleshooting on my
end or temporally installing Classi
>
>
> THAT we do have. The user interface is not very intuitive or friendly at
> all,
> but I just tested it in Thorn, and it does work.
>
> 1. Assign a track to "Synth Plugin #1"
> 2. Hit the Plugin button
> 3. Pick Fluidsynth-DSSI
> 4. Hit the editor button
> 5. Load a soundfont
> 6. Go back to
On Tuesday 22 September 2009, Clem, Brian T. wrote:
> Can the following be done?
> Create a software programmable button in Rosegardens' GUI similar to a
> hardware programmable button found on Logitech's G15 keyboard (used when
> running Windows).
>
> 1. Device: Synth Plugin
> 2. Instrument Param
RG Team,
I have a question regarding steps I frequently perform and whether they can be
'macro'd' or scripted (I hope I am using correct terminology).
Can the following be done?
Create a software programmable button in Rosegardens' GUI similar to a hardware
programmable button found on Logi
Dear Chris and Brett,
Thank you for the information.
I did a test run, and nothing popped up that I can not handle. Looks like some
minor conflicts and some code shuffling into the NoteRestInserter will do the
trick.
I will start tomorrow on the real merge. I have a couple tidy issues I noti
On Fri, Sep 4, 2009 at 5:32 PM, Julie S wrote:
> 1. How do you "resolve" conflicts? Probably a big question.
>
> 2. with the different parts of foo.c what is r715, and r8119 telling me? My
> guess would be that it means the revision number that there is a conflict.
>
> ...
>
> I'm happy to use
On Fri, Sep 4, 2009 at 10:32 PM, Julie S wrote:
> In the case of a conflict, there will be 'C' in the place of the file which
> contained conflicts.
>
> C foo.c
>
> Such a file will be split into several parts.
>
> foo.c
> foo.c.r8115
> foo.c.r8119
> foo.c.working
These files are created by svn
Hello All,
I've been reading up on how to merge notation_toolbar_2 branch, but have a
question about resolving conflicts (I haven't actually tried the merge yet, so
this may not even apply)
>From RG's dev:branching wiki page:
*** BEGIN ***
Resolving conflicts
In the case of a conflict, there w
On Thursday 13 November 2008, Henrik Andersson wrote:
> That is what i mean, think of handling CC as the temporuler with
> keypoints.
Which still doesn't completely work after all this time. It's not exportable
to MIDI files.
--
D. Michael McIntyre
---
Hello
> See it like this, if we want a smooth CC change there would be ALOT of
> dots visually represented that somehow would get hard to work with, as
> if we check on the TempoRuler
> there as keypoints but a tempochange is sent between 2 keypoints when a
> "ramp" is used...
> That is what i mea
, think of handling CC as the temporuler with
keypoints.
/Henrik
<-Ursprungligt Meddelande->
From: Tommi Sakari Uimonen [EMAIL PROTECTED]
Sent: 12/11/2008 9:24:44 PM
To: [EMAIL PROTECTED]
Cc: rosegarden-devel@lists.sourceforge.net
Subject: Re: [Rosegarden-devel] Questio
Hello
> I'm reading up on all discussions and realize that i shouldn't put more
> time into this before we have moved to qt4.
Now that I recall, I came to the same conclusion that I should wait for
the qt4 version, before modifying the control rulers thingy.
> Another thought of CC is this, a C
to the shelf for now.
/Henrik
<-Ursprungligt Meddelande->
From: D. Michael McIntyre
[EMAIL PROTECTED]
Sent: 12/11/2008 3:27:39 AM
To: rosegarden-devel@lists.sourceforge.net
Subject: Re: [Rosegarden-devel] Question concerning rev. 9523
On Tuesday 11 November 2008, Julie
Dear Michael,
> Let's not. Pick something and stick with it. We have
> too many configurable
> doodads as it is. Way too many.
>
> I don't have a vested interest in what you guys pick,
> but I do have a vested
> interest in trying to put the brakes on having too many
> configurable doodads.
On Tuesday 11 November 2008, Julie S wrote:
> So, my answer is, I like both methods. Can we have all the methods options
> available and switch among them: Diamonds, thin bars, and continuous bars?
Let's not. Pick something and stick with it. We have too many configurable
doodads as it is. Wa
2008/11/11 Henrik Andersson <[EMAIL PROTECTED]>:
>
>
> When a series of events are inserted, for a example as the line draw tool,
> set the duration of event to fill up to next time where next event in serie
> is insert.
> This will make the series of events display in a consistent chart without
>
Dear Henrik,
You wrote:
> My suggestion to that is represented in 2 cases:
>
> When a single event is created @ a time, use an as minimal
> duration as
> possible making it more visible distinctive as an event in
> time and not
> something with a duration.
>
> When a series of events are insert
nts on this thoughts?
<-Ursprungligt Meddelande->
From: Chris Cannam [EMAIL PROTECTED]
Sent: 11/11/2008 10:30:31 AM
To: [EMAIL PROTECTED]
Cc: rosegarden-devel@lists.sourceforge.net
Subject: Re: [Rosegarden-devel] Question concerning rev. 9523
I haven't te
Hello All,
Tommi:
Good to hear from you. Yes, I remember having talks with you concerning
updating the event ruler. As this was all unfolding, I was thinking of that
conversation. Good to hear you are still here.
Hendrik;
Thank you for the clarification of your project. So, what I'm seeing
I haven't tested this patch yet and I don't want to distract anyone
from answering Julie's query, but I would like to comment on one thing
in the patch:
int width=m_rulerScale->getXForTime(e->getDuration());
The mapping from time to pixel position provided by a RulerScale is
not necessarily l
Hello,
Maybe someone can clarify this for me.
hean01 submitted patch 9523:
> Log Message:
>---
>Support for adding events with different durations.
>
>Modified Paths:
>--
>trunk/rosegarden/src/gui/rulers/ControlRulerEventInsertCommand.cpp
>trunk/rosegarden/src/gui/rule
On Fri, Sep 26, 2008 at 3:38 PM, Chris Cannam
<[EMAIL PROTECTED]> wrote:
> No, you aren't misunderstanding anything. Rosegarden is very
> simplistic in this respect -- it mixes the number of audio outputs up
> or down to match the number of channels on the track, which is always
> either 1 or 2 de
On Fri, Sep 26, 2008 at 3:38 PM, Chris Cannam
<[EMAIL PROTECTED]> wrote:
> No, you aren't misunderstanding anything. Rosegarden is very
> simplistic in this respect -- it mixes the number of audio outputs up
> or down to match the number of channels on the track, which is always
> either 1 or 2 de
On Fri, Sep 26, 2008 at 3:38 PM, Chris Cannam
<[EMAIL PROTECTED]> wrote:
> No, you aren't misunderstanding anything. Rosegarden is very
> simplistic in this respect -- it mixes the number of audio outputs up
> or down to match the number of channels on the track, which is always
> either 1 or 2 de
On Fri, Sep 26, 2008 at 3:28 PM, yicky yacky <[EMAIL PROTECTED]> wrote:
> Does Rosegarden mix-down all the audio outputs of a given synth before
> feeding the signal to its own internal signal path, or am I
> misunderstanding something / being an idiot?
No, you aren't misunderstanding anything. R
Hello,
I've been developing a toy DSSI plugin, partly to become more familiar
with the spec and partly as a platform for writing base code for use
with less toy instruments. I've been using Rosegarden and
jack-dssi-host as test hosts.
All was going well until I increased the number of DSSI / LADS
Hi Marco,
On Thu, Jun 5, 2008 at 6:28 AM, Marco Costa
<[EMAIL PROTECTED]> wrote:
> Hi guys, I loved the software, and I'm wondering if you use Eclipse with CDT
> since i saw some file with cdt on it when downloading from SVN. I like C++
> maybe I can help with something easy, since becoming a musi
Hi guys, I loved the software, and I'm wondering if you use Eclipse with CDT
since i saw some file with cdt on it when downloading from SVN. I like C++
maybe I can help with something easy, since becoming a music student full
time my programming skills are probably rusty.
And I'd like to suggest a
Guillaume Laurent <[EMAIL PROTECTED]> wrote:
>On Monday 22 March 2004 11:47, Chris Cannam wrote:
>> Anyone know any reason we shouldn't call setsid() to get a new process
>> group right at the start of the GUI's main()?
>
>A quick googling didn't reveal any, and I can't think of any either.
Neithe
On Monday 22 March 2004 11:47, Chris Cannam wrote:
> Anyone know any reason we shouldn't call setsid() to get a new process
> group right at the start of the GUI's main()?
A quick googling didn't reveal any, and I can't think of any either.
--
Guil
Anyone know any reason we shouldn't call setsid() to get a new process
group right at the start of the GUI's main()?
When you run Rosegarden from the KDE desktop it starts up with the
same process group ID as kdeinit, which means if anything gets in a
panic and tries to kill the process group,
45 matches
Mail list logo
