kguitar-devel Mailing List for KGuitar

Hi,

> I would very much like to contribute to kguitar, but the project appears
> to be dead. I would very much like to know that if I send some patches,
> somebody would be there to act on it... (sorry if it sounded rude)

Sorry for long time to answer - got this message in the spam box and
missed it, but indeed, I'm here and ready to act. Project is pretty
stalled, you're right, but not entirely dead. You're welcome to send
patches, and I would be very glad to welcome new contributors in
KGuitar.

-- 
WBR, Mikhail Yakshin

Hi!

I would very much like to contribute to kguitar, but the project appears 
to be dead. I would very much like to know that if I send some patches, 
somebody would be there to act on it... (sorry if it sounded rude)

Regards

On Tue, 06 Jul 2010 16:58:08 Mark Di Nicola wrote:
> > I got kinda' distracted with a pet project but I can jump back onto it.
> 
> How far along did you get?
> 
I had moved a little more of the interface to KDE4 and updated
the help information.

I stopped when I messed my computer up under mysterious circumstances.
Check the logs for further details.
-- 
Quote of the login:
In every non-trivial program there is at least one bug.

On Tue, Jul 6, 2010 at 8:58 AM, Mark Di Nicola <ma...@di...> wrote:
>> I got kinda' distracted with a pet project but I can jump back onto it.
>
> How far along did you get?

KDE4 port is available in Subversion now and it's basically usable. It
lacks several features (namely, track pane and proper synchronization
of track pane and list).

I fix and commit stuff there occasionally, as the time permits.

-- 
WBR, Mikhail Yakshin

> I got kinda' distracted with a pet project but I can jump back onto it.

How far along did you get?

On Tue, 06 Jul 2010 15:28:27 Mark Di Nicola wrote:
> Hi, I've got some time on my hands and am interested in helping out with
> the kde4 port. I noticed some commits a few months ago by Ryan. Is
> anything still happening with that?
> 
I got kinda' distracted with a pet project but I can jump back onto it.


-- 
Quote of the login:
In every non-trivial program there is at least one bug.

Hi, I've got some time on my hands and am interested in helping out with the kde4 port. I noticed some commits a few months ago by Ryan. Is anything still happening with that?

Mark

Hello
I want to extract the names of instruments used in a gp3/gp4 tab file.
Had a look at the KGuitar source but could not figure out how to get  
instruments.
Wondering if you know where I can start looking? Is there a  
specification of the format somewhere?
Any KGuitar code I should have a look at? Been looking in  
convertgp3.cpp but cant figure out how to extract the data I want.

/Niklas

Hello,

I'm the main developper of ktabedit (http://ktabedit.sf.net) which is
a fork of kguitar,
theses days I've published a new version I worked a lot
there is an initial support of classical notation(with a new rendering
engine), a very
good support of gpro 3 and 4 and a lot of beautifull things :D

Maybe we can work together or can you put a link to my project ?

Gwena=EBl Casaccio

Hi Guillame,

the guy to ask would be Mikhail Yakshin, but I haven't heard from him in a 
long time and I am not even sure he reads the mailing list these days. 
Development seemed to stop about a year ago.

In case nobody responds, if you have questions I could try to answer them.

As both RoseGarden and KGuitar are GPL, I guess you should feel free to reuse 
whatever you like, but thanks for asking anyway.

Regards, Leon.

On Sunday 12 March 2006 20:02, Guillaume Laurent wrote:
> Hi,
>
> I'm one of the developpers of Rosegarden. These days we're looking at how
> to add guitar-related features to RG. Some work has already been started,
> but we looked at KGuitar and found that it had a lot of the features we'd
> like to implement.
>
> The code bases are completely different, and looking at the last messages
> on this list's archives it seems nobody on your side would have the time to
> work on this, so there's little chance that this will lead to anything, but
> it's worth asking anyway :-).
>
> In any case, do we have your permission to blatantly rip some of your code
> ? It's in GPL of course but it's more courteous to ask :-).

Hi,

I'm one of the developpers of Rosegarden. These days we're looking at how to 
add guitar-related features to RG. Some work has already been started, but we 
looked at KGuitar and found that it had a lot of the features we'd like to 
implement.

The code bases are completely different, and looking at the last messages on 
this list's archives it seems nobody on your side would have the time to work 
on this, so there's little chance that this will lead to anything, but it's 
worth asking anyway :-).

In any case, do we have your permission to blatantly rip some of your code ? 
It's in GPL of course but it's more courteous to ask :-).

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

Hi, Felipe!

> What is the current KGuitar status? I've taken a look at the cvs repository 
> and the mail archives, the project is pretty much dead since the last 
> release. Is it so?

KGuitar development is somewhat stalled right now. I don't have much 
time to contribute and, sadly, other team members also seem to be inactive.

KGuitar v0.5 marked a pretty good milestone, however, much more things 
have to be improved...

-- 
WBR, GreyCat

Hello.
What is the current KGuitar status? I've taken a look at the cvs repository 
and the mail archives, the project is pretty much dead since the last 
release. Is it so?

PS: please CC me, I'm not suscribed to the list.
-- 


 Felipe Sateler

Hello!

Sorry for late answer, my graduation is coming soon, so I yet again had
to keep KGuitar tasks to minimum.

>>I did an experimental fork of system with thread-based MIDI playback
>>handling. Alas, it produced more problems than solved. Thread handling
>>seems to be pretty unstable and I'm almost lost trying to fix all the
>>emerging bugs. If you want (=willing to test and debug it), I can commit
>>it to CVS or just put a tarball with these patches somewhere.
> 
> I would like to try it. It is no matter whether you will commit it to the CVS or
> will make a tarball. Just let me know.

I've uploaded it to

http://kguitar.sf.net/kguitar-src.tar.bz2

You may try it if you want and see if you can fix all the threading
issues... It is _runnable_ and work pretty much all the time, until you
start doing more complex thing like traversing menus while playing or
something like that. Alas, I barely understand Qt threading model and
it's usability in terms of TSE3 :(

>>>About MIDI playback I think that should be created an abstract layer
>>>and kguitar should using it istead directly using TSE3 library.
>>>The calls to TSE3 should be wrapped in a class that inherit this layer.
>>>This approch will make MIDI playback more flexible and
>>>will not depend on TSE3 only. It will provide an easy way for
>>>supporting multiple libraries. OK, this is just an idea.
>>
>>NoteEdit does that, and, well, I don't see much flexibility in this
>>idea. It seems to just overbloat and overcomplicate the code :(
>> 
> I didn't see the code of NoteEdit, but I'll take a look of it's solution.
> The flexibility is to be able easy to introduce new functionallity.
> Reducing dependency of the code will make it easier for support.
> The code is full wilt #ifdef WITH_TSE3. 
> Using conditional compilation makes the code complicated.
> 
> The main idea of this abstraction is to separate the main code 
> of the application from the MIDI playback stuff.

[skip]

> Why do you think that this solution is complicated
> and overbloat? You already
> have written the code for playing MIDI, just move it 
> to the class MidiTSE3. 

I've tried to do all the stuff you've mentioned in the sources I've
uploaded. There is a new class - Playback, that does just that - handles
almost all MIDI stuff.

However, it's all not that simple. There is, for example, TabSong, the
central data object, that should have methods like midiSong() that
convert it to MIDI to further playback *or*, preferably, it should have
a method that returns special TSE3 iterator for playback, making it
"TSE3::Playable" (implementing that interface).

> Something about song importing:
> If the object pointed from song pointer passed through the constructor 
> of the Convert class (TabSong *) is modified
> and load() return FALSE KGuitar crashes. The reason is that in case of
> invalid importing SongView is not refreshed (I think).
> 
> The right solution (I think) is kguitar_part.cpp openFile() to create
> a temporary song object and to pass its pointer to the load() function
> And only if the load() return TRUE, assign temporary song object to SongView.
> In case of error existing song object won't be modified.
> This solution will make importing more safety.

[skip]

> I think this should work :)

Yes, I completely agree with you here. Thanks for your input.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:gr...@al...]

Hi,

There is nothing strange about these bytes:

// Mysterious padding: must be 43 04 04 00 (for 4.00 format)
kdDebug() << "PAD: " << readDelphiInteger() << " (must be 263235)\n";

According to the documentation about GP4 file format on the=20
site of DGuitar (http://dguitar.sourceforge.net/GP4format.html)=20
these bytes are interpreter as follow:

Measure's header - 0x43
Numerator of the (key) signature - 0x04
Denominator of the (key) signature - 0x04
Tonality of the measure (or new key signature) - 0x00 (C)
=09two bytes are used:
=09- first byte is 'type'
=09- second byte is 'mode' : 0 - major or 1 - minor
=09
In the current implementation you will interpret the second byte=20
of the key signature (mode) as a new measure's header and
if it is 0 - everything will work OK ;), but
in every other case the result is unpredictable :(

These bytes are part from the bar properies (meansures)=20
and you should process them in readBarProperties()
Just comment the line:
kdDebug() << "PAD: " << readDelphiInteger() << " (must be 263235)\n";

----

About number of frets and the drum tracks - you
can determine if the track is a drum from
the first byte in the track properties:

From DGuitar docs:
The first byte is the track's header. =20
It precises the track's attributes:
    __
 7 |__| <- Blank bit;
 6 |__| <- Blank bit;
 5 |__| <- Blank bit;
 4 |__| <- Blank bit;
 3 |__| <- Blank bit;
 2 |__| <- Banjo track;
 1 |__| <- 12 stringed guitar track;
 0 |__| <- Drums track.

bye.

Hi!

> I create a small library for that try to import guitar pro 3 for the moment but
> I try to add a writing support and also a guitar pro 4 support.
> You can go http://libguitarpro.berlios.de/index.html
> 
> I'm the main programmer of kguitartmp
> (http://kguitartmp.sourceforge.net/) I send mails to graycat but I
> don't see responces...
> 
> I look forward to hearing from you

Sorry for all the late responses.

Just to sum the things up:

1. Gwenael, I would be really glad to invite you personally to join
KGuitar team if you're willing to continue development. Please tell me
your SF login so I can grant you R/W access to primary KGuitar CVS, so
you can improve things there, without unnecessary forking. We're open to
any innovations.

2. I did a pretty working (at least from my point of view, though it's
*much* more to do there, but it works for most file I've encountered)
GP4 loader and it's already even in the last release KGuitar version.
Please, take a look at that code, I think it's pretty extendable and
commented to get on with it.

If we *really* need to support GP3 - I'm all hands up for this
initiative, but please, let's not fork and re-write all the same stuff
we're working on. Supporting GP3 in fact is pretty easy: there are just
a few tweaks need to be done to existing GP4 loader.

For all you Guitar Pro reverse engineering folks: do you know that there
is already a project that did all the hard work and wrote all the GP
specs - it's DGuitar (http://dguitar.sourceforge.net/), and it _already_
works pretty well with total majority of Guitar Pro v2, v3 and v4 files.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:gr...@al...]

Nikolay Nikolov wrote:
> Hi,
> 
> The number of frets in a drum track can be more than 24 (MAX_FRETS)
> and in that case kguitar crash in Fretboard.cpp - 
> buffer (double fr[MAX_FRETS + 1]) overflow
> 
> I've make some tests with importing of a Guitar Pro 4 files (v4.06)
> It seems to me that the track patch is not imported correctly.
> 
> I think that the code for setting the patch in function
> ConvertGtp::readTrackProperties() should be modified.
> 
> the code:
> trk->patch = trackPatch[i];
> 
> should be replaced with:
> trk->patch = trackPatch[trk->channel-1];
> 
> OK, I think that should be added and some checks 
> (for example - trk->channel > 0 && trk->channel <= sizeof (trackPatch)
> / sizeof (int))
> for invalid values to prevend crashing of kguitar
> in case of invalid (or unsupported) Guitar Pro file.
> 
> Cheers :)

Thanks for your input, I'll try to fix these things as you said as soon
as possible.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:gr...@al...]

Hi!

Sorry for pretty late answer, I once again was gotten over with real life :(

> I'm greatly impressed by KGuitar, primary by the idea, rather than its
> functionality ;)
> It is in an early stage yet, but I think it has got a lot of potential.

Well, basically, you're right ;)

> Lately, I'm playing with a bug that I found in version 0.5
> When I open second file, it is opened in a new window, but
> if I close this window during playack, the KGuitar crashes.
> 
> I found that SongView::playSong invoke processEvents in
> a cycle. When I click on the close button, processEvents
> delete the SongView object and on the next execution of 
> transport->poll() kguitar crashes (transport object is already deleted ;)
> 
> I think that using of processEvents is not a good idea.
> I'm not enough familiar with kguitar (yet), 
> but a better aproach is using of a thread or even a timer.

I did an experimental fork of system with thread-based MIDI playback
handling. Alas, it produced more problems than solved. Thread handling
seems to be pretty unstable and I'm almost lost trying to fix all the
emerging bugs. If you want (=willing to test and debug it), I can commit
it to CVS or just put a tarball with these patches somewhere.

> About MIDI playback I think that should be created an abstract layer
> and kguitar should using it istead directly using TSE3 library.
> The calls to TSE3 should be wrapped in a class that inherit this layer.
> This approch will make MIDI playback more flexible and 
> will not depend on TSE3 only. It will provide an easy way for 
> supporting multiple libraries. OK, this is just an idea.

NoteEdit does that, and, well, I don't see much flexibility in this
idea. It seems to just overbloat and overcomplicate the code :(

> Another problem that I found are memory leaks in KGuitarPart::openFile()
> and KGuitarPart::saveFile().
> The "ConvertBase *converter" and "QFileInfo *fi" objects are not deleted.

Thanks! I'll try to fix it soon.

> Finaly I want to say that creating of a new window on every opening of
> a file is
> very confusing for me, furthermore there is no close file option.
> My opinion is that the user should have option to open new file (or
> create new file)
> in the same window and also to be able to close a file.

Hmm... I did that following some kind of old KDE HID guidelines, but may
be we should revise this one?

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:gr...@al...]

Gwena=EBl Casaccio wrote:

>I create a small library for that try to import guitar pro 3 for the mom=
ent but
>I try to add a writing support and also a guitar pro 4 support.
>You can go http://libguitarpro.berlios.de/index.html
> =20
>
You might want to have a look to=20
http://cvs.sourceforge.net/viewcvs.py/libgp3/CVSROOT/src/gp3.c?rev=3D1.1&=
view=3Dmarkup
It's the gp3 loader I wrote, that is able to load all gp3 on my hard disk=
.

Here are specs of the gtp/gp3/gp4 file formats, written by BLam from my=20
first gtp/gp3 loader and that I used to write this second version.
http://cvs.sourceforge.net/viewcvs.py/libgp3/CVSROOT/src/gp_file_spec?rev=
=3D1.1&view=3Dmarkup

Feel free to browse the whole cvs, as there's also a gtp (v1 & v2)=20
loader and the first release of a not finished yet gp4 loader.

On Sunday 01 May 2005 20:57, Gwena=EBl Casaccio wrote:
> Hello everybody,
>
> I create a small library for that try to import guitar pro 3 for the mome=
nt
> but I try to add a writing support and also a guitar pro 4 support.
> You can go http://libguitarpro.berlios.de/index.html
>
> I'm the main programmer of kguitartmp
> (http://kguitartmp.sourceforge.net/) I send mails to graycat but I
> don't see responces...
>
> I look forward to hearing from you
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r
> _______________________________________________
> kguitar-devel mailing list
> kgu...@li...
> https://lists.sourceforge.net/lists/listinfo/kguitar-devel

Hi Gwena=EBl,

it's good to see you are trying to improve on KGuitar. I am a bit surprised=
=20
that you did not manage to contact Mikhail (Greycat). He hasn't been very=20
active for some time but did relaese a lot of updates not too long ago.=20
Instead of forking, I'd prefer to see your contributions being added to the=
=20
main KGuitar source tree. Maintaining two versions would be a waste of=20
effort.

Best regards, Leon.

Hello everybody,

I create a small library for that try to import guitar pro 3 for the moment=
 but
I try to add a writing support and also a guitar pro 4 support.
You can go http://libguitarpro.berlios.de/index.html

I'm the main programmer of kguitartmp
(http://kguitartmp.sourceforge.net/) I send mails to graycat but I
don't see responces...

I look forward to hearing from you

Hi,

The number of frets in a drum track can be more than 24 (MAX_FRETS)
and in that case kguitar crash in Fretboard.cpp - 
buffer (double fr[MAX_FRETS + 1]) overflow

I've make some tests with importing of a Guitar Pro 4 files (v4.06)
It seems to me that the track patch is not imported correctly.

I think that the code for setting the patch in function
ConvertGtp::readTrackProperties() should be modified.

the code:
trk->patch = trackPatch[i];

should be replaced with:
trk->patch = trackPatch[trk->channel-1];

OK, I think that should be added and some checks 
(for example - trk->channel > 0 && trk->channel <= sizeof (trackPatch)
/ sizeof (int))
for invalid values to prevend crashing of kguitar
in case of invalid (or unsupported) Guitar Pro file.

Cheers :)

Hi,

I'm greatly impressed by KGuitar, primary by the idea, rather than its
functionality ;)
It is in an early stage yet, but I think it has got a lot of potential.

Lately, I'm playing with a bug that I found in version 0.5
When I open second file, it is opened in a new window, but
if I close this window during playack, the KGuitar crashes.

I found that SongView::playSong invoke processEvents in
a cycle. When I click on the close button, processEvents
delete the SongView object and on the next execution of 
transport->poll() kguitar crashes (transport object is already deleted ;)

I think that using of processEvents is not a good idea.
I'm not enough familiar with kguitar (yet), 
but a better aproach is using of a thread or even a timer.

About MIDI playback I think that should be created an abstract layer
and kguitar should using it istead directly using TSE3 library.
The calls to TSE3 should be wrapped in a class that inherit this layer.
This approch will make MIDI playback more flexible and 
will not depend on TSE3 only. It will provide an easy way for 
supporting multiple libraries. OK, this is just an idea.

Another problem that I found are memory leaks in KGuitarPart::openFile()
and KGuitarPart::saveFile().
The "ConvertBase *converter" and "QFileInfo *fi" objects are not deleted.

Finaly I want to say that creating of a new window on every opening of
a file is
very confusing for me, furthermore there is no close file option.
My opinion is that the user should have option to open new file (or
create new file)
in the same window and also to be able to close a file.

Cheers :)

Well, here it is, guys %)

I guess at last we have something good in our field. Hope to have at
least some feedback on this one.

Thanks for all of you, who are still here ;)

-- 
WBR, Mikhail Yakshin

On Sunday 20 March 2005 14:45, Mikhail Yakshin wrote:
> Hello, guys!
>
> I would be really glad to see if any of you are still around, because I
> have some good news at last. If there are none still reading this, it's
> a pity, but then this note will come as some sort of note to myself of
> what has to be done further.
>

Hello Mikhail,

I am still there ... but very busy working on both NoteEdit and MScore.

>
> Now, I really plan to fix 1-3 and make at least a KGuitar 0.5 release.
>

Sounds like a good idea.

> Hope to hear from ya, guys.

Will try to help wherever I can.

Regards, Leon.