I just got this email from Steve below so I though post my reply here.
Yep, I wrote PianoBooster, and I am here on the mailing list you
recommend,
I had a quick look at the http://pianocheater.com web site but as
only have a little eeepc running Ubuntu next to the piano I cannot
easily try cheater out.
I am interested to know what language you used to write cheater in. I
use c++ and QT which works brilliantly cross platform on Linux Window
+ Mac and the RTMIDI library again cross platform.
I began PianoBooster from the start with a musical score (on the
vertical access) and a piano roll on the time access, so it a bit
different from other free piano hero type programs. It is really
designed for those who want to learn to read sheet music. Also there
was nothing like this on available Linux without using Wine,
Interestingly I did consider rotating the display on Piano Booster by
90 deg to make it look a more like a piano roll but like cheater I
would have to make the notes travel from bottom to top like on piano
cheater. In the end I added note names to the score instead. see this
video
There is still some tearing on the display when scrolling which I
don't really know how to fix. Are there any open gl wiz kids on this
list that could help?
>I am interested to know what language you used to write cheater in. I >use c++ and QT which works brilliantly cross platform on Linux Window >+ Mac and the RTMIDI library again cross platform.
Louis:
I looked up the QT website and couldn't entirely understand. Is it freeware? I couldn't find a price, and I wasn't sure that I saw anything about it being open source. The "marketing" presentation of the website looked like there would be a cost.
Also, does QT include a lib that handles the midi chores? A cross-platform midi lib would be very useful. RT Midi looks interesting, but I see it's without MIDI timing, only input and output.
I'm beginning to understand a hair more. It's free, or a zillion dollars, depending on which license I want to develop under. Free sounds good. Say more about the advantages to QT, please.
-P
&&&&&&&&&&&&&&&&
At 05:05 PM 9/8/2009, Louis wrote:
>I am interested to know what language you used to write cheater in. I >use c++ and QT which works brilliantly cross platform on Linux Window >+ Mac and the RTMIDI library again cross platform.
Louis:
I looked up the QT website and couldn't entirely understand. Is it freeware? I couldn't find a price, and I wasn't sure that I saw anything about it being open source. The "marketing" presentation of the website looked like there would be a cost.
Also, does QT include a lib that handles the midi chores? A cross-platform midi lib would be very useful. RT Midi looks interesting, but I see it's without MIDI timing, only input and output.
I guess while everyone's barraging Louis with questions, I'll join in :)
Sooo, that "follow you" mode... Does it track live tempo and adjust the sequencer's tempo to it? I'm just about to add a "follow me" mode. So far, I only have some ideas, no code.
But I think all I'll really need to do is - keep track of the last spot in the "to mimic" tracks - watch for noteons and bump these spots along - turn the spots' time versus current time into a time offset for background tracks to play at - dump background track events out when timer reaches their "per midi event time" plus time offset
I'm wondering if I should sync seq tempo to live tempo, too. (so in between noteon event background events come out in current live tempo) Or play background tracks at average dynamics of live events. Etc, etc. I guess that'll come with some experimentation.
Can't think of ANYthing cooler I'd rather code :)))
What do you use to time the MIDI events, please? RTMIDI appears not to have timing routines. Did you have to "roll your own" timing for all three platforms?
>I am interested to know what language you used to write cheater in. I >use c++ and QT which works brilliantly cross platform on Linux Window >+ Mac and the RTMIDI library again cross platform.
Look for QT open source edition it is totally free of charge it is also free (as in freedom). it used to be licensed (like piano booster) under GPL meaning that commercial companies could not use it without also publishing their source code -- so they also sold a commercial version of QT. Now QT is licensed under LGPL and so there is no obligation to publish the source code.
PianoBooster is copyrighted and protected by the GPL license to stop
some evil company from stealing my source code. This company would then be legally required to publish all their source code for there piano app including any code which I did not write.
I throughly recommend QT (now it is LGPL) as it covers absolutely every thing -- apart from MIDI. Try running the examples to see how easy everything is.
For the timing I just use QTimer see line 331on the link below
Paul A. wrote:
> I'm beginning to understand a hair more. It's free, or a zillion > dollars, depending on which license I want to develop under. Free > sounds good. Say more about the advantages to QT, please.
> -P
> &&&&&&&&&&&&&&&&
> At 05:05 PM 9/8/2009, Louis wrote:
>> I am interested to know what language you used to write cheater in. I
>> use c++ and QT which works brilliantly cross platform on Linux Window
>> + Mac and the RTMIDI library again cross platform.
> Louis:
> I looked up the QT website and couldn't entirely understand. Is it > freeware? I couldn't find a price, and I wasn't sure that I saw > anything about it being open source. The "marketing" presentation of > the website looked like there would be a cost.
> Also, does QT include a lib that handles the midi chores? A > cross-platform midi lib would be very useful. RT Midi looks > interesting, but I see it's without MIDI timing, only input and output.
Follow mode is quite complicated and it must all happen in real time. That is why I did not uses any midi timing libraries as they only introduce unwanted delays. Basically the music must all stop at the stop point and wait for the pianist. Then as soon as the pianist plays the right notes the accompaniment must start playing _immediately_.
As for the tempo I just stick with a percentage that changes the bpm tempo in the midi file.
Steve, have you considered releasing the source code for Piano Cheater?
Regarding the tearing (see link below) it is only noticeable when scrolling _horizontally_ :-(
> I guess while everyone's barraging Louis with questions, I'll join in :)
> Sooo, that "follow you" mode...
> Does it track live tempo and adjust the sequencer's tempo to it?
> I'm just about to add a "follow me" mode.
> So far, I only have some ideas, no code.
> But I think all I'll really need to do is
> - keep track of the last spot in the "to mimic" tracks
> - watch for noteons and bump these spots along
> - turn the spots' time versus current time into a time offset
> for background tracks to play at
> - dump background track events out when timer reaches their
> "per midi event time" plus time offset
> I'm wondering if I should sync seq tempo to live tempo, too.
> (so in between noteon event background events come out in
> current live tempo)
> Or play background tracks at average dynamics of live events.
> Etc, etc. I guess that'll come with some experimentation.
> Can't think of ANYthing cooler I'd rather code :)))
> What do you use to time the MIDI events, please? RTMIDI appears not > to have timing routines. Did you have to "roll your own" timing for > all three platforms?
> -Paul
> At 05:05 PM 9/8/2009, Louis wrote:
>> I am interested to know what language you used to write cheater in. I
>> use c++ and QT which works brilliantly cross platform on Linux Window
>> + Mac and the RTMIDI library again cross platform.
I think we are on different timezones I am in the UK Ham, London (where are you all located?) And no timing does not come from fluidsynth the current release does not used it. but i have done some work on the dev branch integrating it.
I'm in Seattle, WA - USA (PDT) There are at least 2 or 3 others on this list who are, too. But others in the UK and other areas, too.
On Wed, Sep 9, 2009 at 12:37 PM, Louis B.<louisjbar...@googlemail.com> wrote: > Follow mode is quite complicated and it must all happen in real time. > That is why I did not uses any midi timing libraries as they only > introduce unwanted delays.
I hear you on the library biz. I don't use any either. Well, just mine. I don't even use the c run time library. I use Win32 API and that's IT :)
> Basically the music must all stop at the > stop point and wait for the pianist. Then as soon as the pianist plays > the right notes the accompaniment must start playing _immediately_.
Hmm, so when you restart the background tracks, do you send new noteons? Or do you use volume change and bring the tracks to 0 then back up to prev volume? When I pause in my "wait for me" mode, I pause the timer, set volume cc to 0 for all tracks, then restore volume when all noteons are good to go.
> As for the tempo I just stick with a percentage that changes the bpm > tempo in the midi file.
Ah, ok, so you're not adjusting that per user's noteons. That's how I'll start out, too. I'll play with doing that calc, and if it doesn't work out (might be too jumpy ANYway), it gets ripped out...
I'm lookin' forward to writing that code. Just a little more rendering tweaking then I'm on to THAT :)
> Steve, have you considered releasing the source code for Piano Cheater?
Wellllllllll, I've considered it... But considering how well I see people FOLLOWING license specs... Ummm, it seems to me like once the source is OUT there for people to see, well, it's out there for people to do whatever they wish with. I mean, take out all the comments, rename all the variables and now, umm, IS it the same code??? It'd be tough to PROVE per a license that it is or ain't...:/ And I don't wanna deal with lawyers EVER :p
So far, I've stuck with "closed as heck" source...:/
> Regarding the tearing (see link below) it is only noticeable when > scrolling _horizontally_ :-(
You're =sure= it's due to sync'ing with refresh? I'm sure you're probably right, but you might just try taking OUT some drawing code or sound rendering code and see if the tearing magically disappears...
My vertical piano roll was behaving badly for a bit, but after a little performance timing, it was MY drawing code that was too slow.
This probably isn't what you're dealing with, but it SURE gets tough to measure this sort of stuff when your app starts to get "big" :)
So I doubt I'll be much help there, sorry...
Sometimes for me, though, it helps to describe my problem in detail on the email list (even if no one cares:) and the next morning when I wake up, POW, problem solved :)
Your joining this group and the resulting current discussion is an unexpected turn of events. I had just last week definitively decided to use C#/.net/mono for my eartraining project, and have been pondering several issues:
1) How much resistance will I get from users on having to install .net/mono? 2) While there's web examples of how to call to the Win multimedia timing from .net ( http://www.codeproject.com/KB/miscctrl/lescsmultimediatimer.aspx ), how will I make C# handle it under OSX? 3) While there's web examples of how to call to the Win MIDI services from .net ( http://www.lesliesanford.com/Programming/MIDIToolkit.shtml ), how will I make C# handle it under OSX? (Note: Thanks to Leslie Sanford for all of the above-referenced code.) 4) While C# provides Winforms for GUI handling, and such a GUI should, in theory, run well under mono, I've heard from numerous people that Mac users are very particular about buying programs that have an authentic Mac look and feel. In other words, a cross-platform GUI, no matter how well it works, could fall somewhat flat for marketing reasons.
Your suggestion to use C++/QT/RTmidi appears to solve problem #1-3 above, but perhaps leaves open the question of whether a cross-platform Win-ish GUI will fly with Mac consumers. I assume, perhaps wrongly, that QT will run with a Win look under OSX. Yes?
Another issue is that I just don't love C++. After spending years with Delphi, I'd much rather make a learning commitment to, and have a code base in, C#.
>Look for QT open source edition it is totally free of charge it is also >free (as in freedom). it used to be licensed (like piano booster) under >GPL meaning that commercial companies could not use it without also >publishing their source code -- so they also sold a commercial version >of QT. Now QT is licensed under LGPL and so there is no obligation to >publish the source code.
>PianoBooster is copyrighted and protected by the GPL license to stop >some evil company from stealing my source code. This company would then >be legally required to publish all their source code for there piano app >including any code which I did not write.
>I throughly recommend QT (now it is LGPL) as it covers absolutely every >thing -- apart from MIDI. Try running the examples to see how easy >everything is.
>For the timing I just use QTimer see line 331on the link below
>On windows QTimer is a wrapper round the Windows multimeadia timer.
>I did not want any of that timing junk in a midi library as piano >booster works in real time. So Rt midi is perfect for me.
>Louis
>Paul A. wrote: > > I'm beginning to understand a hair more. It's free, or a zillion > > dollars, depending on which license I want to develop under. Free > > sounds good. Say more about the advantages to QT, please.
> > -P
> > &&&&&&&&&&&&&&&&
> > At 05:05 PM 9/8/2009, Louis wrote: > >> I am interested to know what language you used to write cheater in. I > >> use c++ and QT which works brilliantly cross platform on Linux Window > >> + Mac and the RTMIDI library again cross platform.
UIs made with Qt appear native under each platform. I'm also
developing an application with Qt and RtAudio (RtMidi's bro), and even
the "under construction" UI of my app looks better under OS X than
Windows Vista.
As for runtimes, there is none to install with Qt, you just deploy the
libraries you use along with your app. I'm also coming from Delphi and
the learning curve isn't that steep. In short, if you care about
having a cross platform app, definitely look into Qt.
Utku Uzmen
On Sep 10, 10:06 am, "Paul A." <sanitat...@earthlink.net> wrote:
> Your joining this group and the resulting current discussion is an
> unexpected turn of events. I had just last week definitively decided
> to use C#/.net/mono for my eartraining project, and have been
> pondering several issues:
> 1) How much resistance will I get from users on having to install .net/mono?
> 2) While there's web examples of how to call to the Win multimedia
> timing from .net (http://www.codeproject.com/KB/miscctrl/lescsmultimediatimer.aspx),
> how will I make C# handle it under OSX?
> 3) While there's web examples of how to call to the Win MIDI services
> from .net (http://www.lesliesanford.com/Programming/MIDIToolkit.shtml), how
> will I make C# handle it under OSX? (Note: Thanks to Leslie
> Sanford for all of the above-referenced code.)
> 4) While C# provides Winforms for GUI handling, and such a GUI
> should, in theory, run well under mono, I've heard from numerous
> people that Mac users are very particular about buying programs that
> have an authentic Mac look and feel. In other words, a
> cross-platform GUI, no matter how well it works, could fall somewhat
> flat for marketing reasons.
> Your suggestion to use C++/QT/RTmidi appears to solve problem #1-3
> above, but perhaps leaves open the question of whether a
> cross-platform Win-ish GUI will fly with Mac consumers. I assume,
> perhaps wrongly, that QT will run with a Win look under OSX. Yes?
> Another issue is that I just don't love C++. After spending years
> with Delphi, I'd much rather make a learning commitment to, and have
> a code base in, C#.
> Any comments or suggestions? Much appreciated!
> -Paul
> At 03:04 PM 9/9/2009, Louis wrote:
> >Hello Paul,
> >Look for QT open source edition it is totally free of charge it is also
> >free (as in freedom). it used to be licensed (like piano booster) under
> >GPL meaning that commercial companies could not use it without also
> >publishing their source code -- so they also sold a commercial version
> >of QT. Now QT is licensed under LGPL and so there is no obligation to
> >publish the source code.
> >PianoBooster is copyrighted and protected by the GPL license to stop
> >some evil company from stealing my source code. This company would then
> >be legally required to publish all their source code for there piano app
> >including any code which I did not write.
> >I throughly recommend QT (now it is LGPL) as it covers absolutely every
> >thing -- apart from MIDI. Try running the examples to see how easy
> >everything is.
> >For the timing I just use QTimer see line 331on the link below
> >On windows QTimer is a wrapper round the Windows multimeadia timer.
> >I did not want any of that timing junk in a midi library as piano
> >booster works in real time. So Rt midi is perfect for me.
> >Louis
> >Paul A. wrote:
> > > I'm beginning to understand a hair more. It's free, or a zillion
> > > dollars, depending on which license I want to develop under. Free
> > > sounds good. Say more about the advantages to QT, please.
> > > -P
> > > &&&&&&&&&&&&&&&&
> > > At 05:05 PM 9/8/2009, Louis wrote:
> > >> I am interested to know what language you used to write cheater in. I
> > >> use c++ and QT which works brilliantly cross platform on Linux Window
> > >> + Mac and the RTMIDI library again cross platform.
> Follow mode is quite complicated and it must all happen in real time.
> That is why I did not uses any midi timing libraries as they only
> introduce unwanted delays. Basically the music must all stop at the
> stop point and wait for the pianist. Then as soon as the pianist plays
> the right notes the accompaniment must start playing _immediately_.
> As for the tempo I just stick with a percentage that changes the bpm
> tempo in the midi file.
> Steve, have you considered releasing the source code for Piano Cheater?
> Regarding the tearing (see link below) it is only noticeable when
> scrolling _horizontally_ :-(
> > I guess while everyone's barraging Louis with questions, I'll join in :)
> > Sooo, that "follow you" mode...
> > Does it track live tempo and adjust the sequencer's tempo to it?
> > I'm just about to add a "follow me" mode.
> > So far, I only have some ideas, no code.
> > But I think all I'll really need to do is
> > - keep track of the last spot in the "to mimic" tracks
> > - watch for noteons and bump these spots along
> > - turn the spots' time versus current time into a time offset
> > for background tracks to play at
> > - dump background track events out when timer reaches their
> > "per midi event time" plus time offset
> > I'm wondering if I should sync seq tempo to live tempo, too.
> > (so in between noteon event background events come out in
> > current live tempo)
> > Or play background tracks at average dynamics of live events.
> > Etc, etc. I guess that'll come with some experimentation.
> > Can't think of ANYthing cooler I'd rather code :)))
I'm curious whether you first researched C#/.net/mono, considered some of the same (and different) questions as I did, and turned it down. If so, what ultimately decided you in favor of C++/Qt/RtMidi, please?
Also, I'm completely Mac-ignorant, but regarding "look and feel": isn't there also a "feel" issue that goes beyond simply the initial cosmetics of the OSX version? I.e., aren't there certain Mac-user-approved GUI behavior styles that need to be worked out by the programmer, that would be different than in a Win context?
>UIs made with Qt appear native under each platform. I'm also >developing an application with Qt and RtAudio (RtMidi's bro), and even >the "under construction" UI of my app looks better under OS X than >Windows Vista.
>As for runtimes, there is none to install with Qt, you just deploy the >libraries you use along with your app. I'm also coming from Delphi and >the learning curve isn't that steep. In short, if you care about >having a cross platform app, definitely look into Qt.
> I assume, perhaps wrongly, that QT will run with a Win look under OSX. Yes?
Ha ha, they fooled you then! QT widgets not are native to ether
Windows or the MAC they are just emulated to look like they are native
widgets. They do a very good job on both the windows and mac.
> Another issue is that I just don't love C++.
But Qt does make life easier with a good toolkit and their Implicitly
Shared Classes see these links below.
> Is the graphics performance too bad if you don't use OpenGL?
If you want to do any sort of scrolling then you really need to use
hardware acceleration as the whole screen needs to redrawn every
frame.
When to uses hardware acceleration is not a QT issue (QT graphics
performance is fine) but it is a computer issue and applies to any
language and toolkit.
On Thu, Sep 10, 2009 at 8:06 AM, Paul A. <sanitat...@earthlink.net> wrote:
> Louis:
> Your joining this group and the resulting current discussion is an
> unexpected turn of events. I had just last week definitively decided to use
> C#/.net/mono for my eartraining project, and have been pondering several
> issues:
> 1) How much resistance will I get from users on having to install .net/mono?
> 2) While there's web examples of how to call to the Win multimedia timing
> from .net ( http://www.codeproject.com/KB/miscctrl/lescsmultimediatimer.aspx > ), how will I make C# handle it under OSX?
> 3) While there's web examples of how to call to the Win MIDI services from
> .net ( http://www.lesliesanford.com/Programming/MIDIToolkit.shtml ), how
> will I make C# handle it under OSX? (Note: Thanks to Leslie Sanford for
> all of the above-referenced code.)
> 4) While C# provides Winforms for GUI handling, and such a GUI should, in
> theory, run well under mono, I've heard from numerous people that Mac users
> are very particular about buying programs that have an authentic Mac look
> and feel. In other words, a cross-platform GUI, no matter how well it
> works, could fall somewhat flat for marketing reasons.
> Your suggestion to use C++/QT/RTmidi appears to solve problem #1-3 above,
> but perhaps leaves open the question of whether a cross-platform Win-ish GUI
> will fly with Mac consumers. I assume, perhaps wrongly, that QT will run
> with a Win look under OSX. Yes?
> Another issue is that I just don't love C++. After spending years with
> Delphi, I'd much rather make a learning commitment to, and have a code base
> in, C#.
> Any comments or suggestions? Much appreciated!
> -Paul
> At 03:04 PM 9/9/2009, Louis wrote:
> Hello Paul,
> Look for QT open source edition it is totally free of charge it is also
> free (as in freedom). it used to be licensed (like piano booster) under
> GPL meaning that commercial companies could not use it without also
> publishing their source code -- so they also sold a commercial version
> of QT. Now QT is licensed under LGPL and so there is no obligation to
> publish the source code.
> PianoBooster is copyrighted and protected by the GPL license to stop
> some evil company from stealing my source code. This company would then
> be legally required to publish all their source code for there piano app
> including any code which I did not write.
> I throughly recommend QT (now it is LGPL) as it covers absolutely every
> thing -- apart from MIDI. Try running the examples to see how easy
> everything is.
> For the timing I just use QTimer see line 331on the link below
> On windows QTimer is a wrapper round the Windows multimeadia timer.
> I did not want any of that timing junk in a midi library as piano
> booster works in real time. So Rt midi is perfect for me.
> Louis
> Paul A. wrote:
>> I'm beginning to understand a hair more. It's free, or a zillion
>> dollars, depending on which license I want to develop under. Free
>> sounds good. Say more about the advantages to QT, please.
>> -P
>> &&&&&&&&&&&&&&&&
>> At 05:05 PM 9/8/2009, Louis wrote:
>>> I am interested to know what language you used to write cheater in. I
>>> use c++ and QT which works brilliantly cross platform on Linux Window
>>> + Mac and the RTMIDI library again cross platform.
I tried to read the LGPL specs and it was a bit over my head. If I can use QT open source edition to create software that I will sell, and I don't have to publish the source code, why would anyone ever buy the comm'l version? Or is it that QT open source edition projects have to be distributed as freeware?
>Look for QT open source edition it is totally free of charge it is also >free (as in freedom). it used to be licensed (like piano booster) under >GPL meaning that commercial companies could not use it without also >publishing their source code -- so they also sold a commercial version >of QT. Now QT is licensed under LGPL and so there is no obligation to >publish the source code.
Turns out that there is a C#/.net/mono/Qt project and community. Not sure how much more aggravation learning and using the binding technology would be than just using C++.
I'll admit that I didn't really look into C#/.net because many (most?)
"serious" audio apps are written in C++ (with performance critical
parts sometimes in C or Assembly). I wanted to get the best
performance possible, but honestly I didn't have much time for running
C++ vs C# benchmarks.
Yes there is the issue of look and feel beyond simply recompiling your
app under OS X, but Qt has some provisions to use platform specific
functions. For example, in a Windows app, if you want to warn a user
about something, you might show a message box, while in OS X, the same
warning might be shown as a sheet. With Qt you can simply construct a
message box with the "this is really a sheet" flag. It will appear as
a sheet in OS X and as a normal message box in Windows. Then there is
the issue of icons etc. which are completely up to the developer.
It seems to me that if you design your app with OS X in mind, you will
please Mac users and Windows users will just be fine because they're
used to even Microsoft not following their own design guidelines.
Utku Uzmen
On Sep 10, 3:22 pm, "Paul A." <sanitat...@earthlink.net> wrote:
> I'm curious whether you first researched C#/.net/mono, considered
> some of the same (and different) questions as I did, and turned it
> down. If so, what ultimately decided you in favor of C++/Qt/RtMidi, please?
> Also, I'm completely Mac-ignorant, but regarding "look and feel":
> isn't there also a "feel" issue that goes beyond simply the initial
> cosmetics of the OSX version? I.e., aren't there certain
> Mac-user-approved GUI behavior styles that need to be worked out by
> the programmer, that would be different than in a Win context?
> -Paul
> At 04:54 AM 9/10/2009, Utku wrote:
> >UIs made with Qt appear native under each platform. I'm also
> >developing an application with Qt and RtAudio (RtMidi's bro), and even
> >the "under construction" UI of my app looks better under OS X than
> >Windows Vista.
> >As for runtimes, there is none to install with Qt, you just deploy the
> >libraries you use along with your app. I'm also coming from Delphi and
> >the learning curve isn't that steep. In short, if you care about
> >having a cross platform app, definitely look into Qt.
On Sep 10, 3:35 pm, "Louis B." <louisjbar...@googlemail.com> wrote:
> Ha ha, they fooled you then! QT widgets not are native to ether
> Windows or the MAC they are just emulated to look like they are native
> widgets. They do a very good job on both the windows and mac.
This is not true in the latest version of Qt. Basic widgets like
buttons, combo boxes, edit boxes, tabs, frames etc. are native.
> I tried to read the LGPL specs and it was a bit over my head. If I > can use QT open source edition to create software that I will sell, > and I don't have to publish the source code, why would anyone ever buy > the comm'l version? Or is it that QT open source edition projects > have to be distributed as freeware?
It was GPL before so only GPL projects could use the open source edition hence the commercial version. they only changed recently LGPL now no one needs the commercial version unless you want all the commercial support.
> At 03:04 PM 9/9/2009, Louis wrote:
>> Look for QT open source edition it is totally free of charge it is also
>> free (as in freedom). it used to be licensed (like piano booster) under
>> GPL meaning that commercial companies could not use it without also
>> publishing their source code -- so they also sold a commercial version
>> of QT. Now QT is licensed under LGPL and so there is no obligation to
>> publish the source code.
|
