Install-recursive and .seq24rc equivalent

[TDeagan]

I succeeded, for the most part, in getting sequencer64 to build on my Raspberry Pi 2 (Raspbian Wheezy). However I've got a couple questions;

• The install built a runnable executable but failed on 'install-recursive':

Makefile:464: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1

Is this relevant to achieving an executable copy?

sudo sequencer-64-master/Sequencer64/sequencer64

runs, but I haven't put it through all its paces yet.

• I can't find anything that looks like the equivalent of .seq24rc after changing a keyboard mapping. I'd like to bring over my Launchpad MIDI config from seq24, but am not sure where to put it. Is there someplace special I should look? Is this possibly an artifact of a build fail?

Thanks, I've spent a fair amount of time in the seq24 source, so I'll start digging into the sequencer64 source soon. I really really want to enhance the mute-group functionality in seq24 and it would be great if sequencer64 was a good platform for that.

Cheers, --tim

[ahlstromcj]

Not sure about the install-recursive error; I don't see that here. I use the default prefix, /usr/local, though, when I install. If you figure it out, let me know and I can look deeper into it.

The configuration files are installed in ~/.config/sequencer64, and there are two files: sequencer64.rc (replaces ~/.seq24rc) and sequencer64.usr (replaces ~/.seq24usr). The former (rc) has only a couple of extensions, but the latter (usr) has a lot more stuff added to it, and it is written the first time you run Sequencer64. The rc is rewritten every time you exit, but the usr is written only if it doesn't exist, or if the --user-save option was used.

My sequencer64-doc.git project documents everything in gory detail, but it is a little bit ahead of the master, as I still have the smf0 branch to merge (after more testing). That branch adds import of SMF 0 file and the option to allow two song editors to be used. If you have any songs that make the app belch, let me know. I'd like to find a large and complex SMF 0. I did find a game MIDI from Sierra, and it seems to load, but it is still only 800K in size.

It would be great if you could not only enhance the mute group functionality, but give me some details on how it works. That is one thing I haven't dug too deep into yet.

I've radically reworked the code to make it easier to grok and update. The same basic classes are still there, though. I eventually want to migrate to Gtkmm-3. Also thinking about a gui-less Sequencer64 just for loading, playing, and live-controlling a tune.

Also note a slew of build options, some in the ./configure, and some by hardwriting macros in the code.

Thanks, and good luck with the code! Hopefully I can get used to pulling changes properly with git. :-)

Chris

-------- Tim Deagan 07:48 Fri 27 Nov --------

I succeeded, for the most part, in getting sequencer64 to build on my Raspberry Pi 2 (Raspbian Wheezy). However I've got a couple questions;

• The install built a runnable executable but failed on 'install-recursive':

Makefile:464: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1

Is this relevant to achieving an executable copy?

sudo sequencer-64-master/Sequencer64/sequencer64

runs, but I haven't put it through all its paces yet.

• I can't find anything that looks like the equivalent of .seq24rc after changing a keyboard mapping. I'd like to bring over my Launchpad MIDI config from seq24, but am not sure where to put it. Is there someplace special I should look? Is this possibly an artifact of a build fail?

Thanks, I've spent a fair amount of time in the seq24 source, so I'll start digging into the sequencer64 source soon. I really really want to enhance the mute-group functionality in seq24 and it would be great if sequencer64 was a good platform for that.

Cheers, --tim

---

Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/2

Exercise caution in your daily affairs.

[TDeagan]

Thanks for the quick reply. Though I've spent hours staring at the seq24 code, the mute group functionality remains completely opaque. They must be using different terminology in the code. On the other hand, looking at the sequencer64 source, the mute group stuff in midifile.cpp is super obvious (though I haven't stepped through it mentally yet.)

I'm going to dig for a little while longer in the seq24 source to see if I can get a handle on how it works, but I'll cut my losses pretty soon and switch over to getting a handle on how it's done in sequencer64. I'd really love to get the mute groups to play nicer with the screen sets than they do in seq24, where they appear to only work against the first screen set, regardless of what set you're on or what's on other sets. That makes it kinda useless to try and use both multiple screen sets and mute groups. Even if I'm stuck with only 32 mute groups, I want them to either A) work with whatever sequences on whatever sets you pick (mixing sequences from multiple sets,) or B) working only on the active screen set (ignoring what's happening on other sets and not caring what sequences are on the active set.)

It'll be tough to do B since different sets may have different sequence slots populated and that impacts the whole active sequence flag logic. It'll be tough to do A since the sequence number will have to be set aware.

I also want to make the MIDI input do start and stop, but it looks like you may have done this or are heading that way (haven't tested yet,) because I see c_midi_control_play_ss defined in your code.

Hoepfully I'll get some time this weekend, I have a deadline on a book I'm writing due, but I should be able to take some breaks and play with this.

Cheers! --tim

[TDeagan]

Oh, and I'll also read the docs and play with the app to actually see what it does instead of trying to guess from source :-) --t

[TDeagan]

Wow! Read through the doc, kudos on the incredible wealth of documentation!! Clearly I misunderstood the significance/function of the 'Set Playing Screenset' key. My midi map of the replace, snapshot and screen-set play keys still aren't giving me love, so I'll keep digging on that.

My compliments again on the doc, that's a huge undertaking and a tremendous boon.

--t

[ahlstromcj]

Thanks! It is evolving.

As far as the mute-groups go, although I have cleaned up the way the code looks, that code should be mostly the same. I try to document what I finally figure out in the code, but there are still some gaps in my knowledge. Seq24 is really a lot "bigger" than it looks from the user-interface. I am taking baby steps, checking often that I haven't broken something.

Also, I have found some functionality that is only partly coded. For example, there's code to support copying SysEx into allocated memory and putting it in the event list, but the parser currently just skips SysEx and moves on to reading the next event.

There's some stuff I've barely touched other than to format the code nicely. The "fruity" mouse support is a good example.

Yeah, I started this project with the idea of adding a textual event view and migrating to the Gtkmm, but it's taken on a life of its own. I just found an SMF 0 file that the import code might not be reading correctly.

Oh, and you probably will find some mistakes in the document, so watch out for traps!

Chris

-------- Tim Deagan 10:17 Fri 27 Nov --------

Wow! Read through the doc, kudos on the incredible wealth of documentation!! Clearly I misunderstood the significance/function of the 'Set Playing Screenset' key. My midi map of the replace, snapshot and screen-set play keys still aren't giving me love, so I'll keep digging on that.

My compliments again on the doc, that's a huge undertaking and a tremendous boon.

--t

---

Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160185297

A vivid and creative mind characterizes you.

[TDeagan]

Sorry to be so slow, all my free time is spent trying to get my upcoming book across its jan15 finish line. But (for deeply nerdy reasons,) I always spend a bunch of my christmas vacation time learning new source code, so I 've set up a Netbeans environment for sequencer64 (I have to confess I'm a Windows developer for a living and really gravitate towards IDEs. I've worked in linux for decades, but linux as an IDE breaks my heart.)

In any event, after some code surfing and debugging, it looks like a lot of the odd behavior I experience with mute groups is possibly because of the line: if ((i == m_playing_screen) && m_tracks_mute_state[j]) in perform::mute_group_tracks () isn't working as I imagined it should.

Gdb tells me that m_playing_screen never changes from 0 regardless of the m_screenset value. I believe this is why, no matter what screen you're on when you hit a mute group key, it ignores that screen and applies the mute group to the first screen.

I'll try i == m_screenset as an alternative sometime in the next few days. I just wanted to let you know I was still thinking about this.

cheers, --Tim

On Fri, Nov 27, 2015 at 1:29 PM, C. Ahlstrom notifications@github.com wrote:

Thanks! It is evolving.

As far as the mute-groups go, although I have cleaned up the way the code looks, that code should be mostly the same. I try to document what I finally figure out in the code, but there are still some gaps in my knowledge. Seq24 is really a lot "bigger" than it looks from the user-interface. I am taking baby steps, checking often that I haven't broken something.

Also, I have found some functionality that is only partly coded. For example, there's code to support copying SysEx into allocated memory and putting it in the event list, but the parser currently just skips SysEx and moves on to reading the next event.

There's some stuff I've barely touched other than to format the code nicely. The "fruity" mouse support is a good example.

Yeah, I started this project with the idea of adding a textual event view and migrating to the Gtkmm, but it's taken on a life of its own. I just found an SMF 0 file that the import code might not be reading correctly.

Oh, and you probably will find some mistakes in the document, so watch out for traps!

Chris

-------- Tim Deagan 10:17 Fri 27 Nov --------

Wow! Read through the doc, kudos on the incredible wealth of documentation!! Clearly I misunderstood the significance/function of the 'Set Playing Screenset' key. My midi map of the replace, snapshot and screen-set play keys still aren't giving me love, so I'll keep digging on that.

My compliments again on the doc, that's a huge undertaking and a tremendous boon.

--t

---

Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160185297

A vivid and creative mind characterizes you.

— Reply to this email directly or view it on GitHub https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160193813 .

[ahlstromcj]

Thanks for the bug report! I've got it logged to investigate soon, but let me know what you find. Also, any info you can add about how to use this feature at a user level would help me.

I'm still beating on an event viewer (a list of all events) and editor, but it has proven a hell of a lot tricker to manage a viewing frame and insertions, deletions, etc.

As for NetBeans, I started using it when our work project started transitioning to Java. It's pretty cool, and I was able to get it to work with a Maven project. The Microsoft fans think VIsual Studio is the best IDE ever, but they are full of it -- it is bloated and awful, and I use it only for debugging our Windows-based code. But NetBeans (and Maven) run on Linux just fine. Most of the guys use Eclipse. If I get into the Java code (I'm the "C++ guy"), I'd probably set up eclim (Vim rulez).

Perhaps I could make the NetBeans setup and additional pack that the user could unpack to enable NetBeans support. Something to think about.

I really appreciate the feedback!

Chris

P.S. What book?

-------- Tim Deagan 20:48 Sat 19 Dec --------

Sorry to be so slow, all my free time is spent trying to get my upcoming book across its jan15 finish line. But (for deeply nerdy reasons,) I always spend a bunch of my christmas vacation time learning new source code, so I 've set up a Netbeans environment for sequencer64 (I have to confess I'm a Windows developer for a living and really gravitate towards IDEs. I've worked in linux for decades, but linux as an IDE breaks my heart.)

In any event, after some code surfing and debugging, it looks like a lot of the odd behavior I experience with mute groups is possibly because of the line: if ((i == m_playing_screen) && m_tracks_mute_state[j]) in perform::mute_group_tracks () isn't working as I imagined it should.

Gdb tells me that m_playing_screen never changes from 0 regardless of the m_screenset value. I believe this is why, no matter what screen you're on when you hit a mute group key, it ignores that screen and applies the mute group to the first screen.

I'll try i == m_screenset as an alternative sometime in the next few days. I just wanted to let you know I was still thinking about this.

cheers, --Tim

On Fri, Nov 27, 2015 at 1:29 PM, C. Ahlstrom notifications@github.com wrote:

Thanks! It is evolving.

As far as the mute-groups go, although I have cleaned up the way the code looks, that code should be mostly the same. I try to document what I finally figure out in the code, but there are still some gaps in my knowledge. Seq24 is really a lot "bigger" than it looks from the user-interface. I am taking baby steps, checking often that I haven't broken something.

Also, I have found some functionality that is only partly coded. For example, there's code to support copying SysEx into allocated memory and putting it in the event list, but the parser currently just skips SysEx and moves on to reading the next event.

There's some stuff I've barely touched other than to format the code nicely. The "fruity" mouse support is a good example.

Yeah, I started this project with the idea of adding a textual event view and migrating to the Gtkmm, but it's taken on a life of its own. I just found an SMF 0 file that the import code might not be reading correctly.

Oh, and you probably will find some mistakes in the document, so watch out for traps!

Chris

-------- Tim Deagan 10:17 Fri 27 Nov --------

Wow! Read through the doc, kudos on the incredible wealth of documentation!! Clearly I misunderstood the significance/function of the 'Set Playing Screenset' key. My midi map of the replace, snapshot and screen-set play keys still aren't giving me love, so I'll keep digging on that.

My compliments again on the doc, that's a huge undertaking and a tremendous boon.

--t

---

Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160185297

A vivid and creative mind characterizes you.

— Reply to this email directly or view it on GitHub https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160193813 .

---

Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-166066418

Your fly might be open (but don't check it just now).

[TDeagan]

I'll try diff'ing the current netbeans sequencer64 folder with a stock one when I get a chance, it looks like there is an nbproject folder in it that may be all that's needed to make it netbeans ready. I did have to run the .bootstrap, .config, make sequence in a terminal before I could get netbeans happy, but that's probably because I didn't spend enough time figuring out the prebuild config it wants. Once I ran the sequence manually, Netbeans picked everything up and seems to be working fine. Alas, all my meager linux dev over the years has either been in Python or QtCreator (I contributed to OpenSCAD for a while,) so the stock toolchain laughs at me.

If the mute functionality is supposed to work like it currently does (a la seq24,) then I'm baffled as to how to explain it concisely. It makes no sense to me. If what I mentioned above truly is a bug (going back into the seq24 code,) then I can picture a straightforward way to explain. But there are still some choices to make. A) Is mute an overlay on the playing screen's tracks? If so, what should happen to tracks playing on other screens? Ignored, same overlay applied to every screen? All other screens' tracks off? B) Is mute globally applied? If so, can you mix and match tracks from different screens?

I tend to think, from the size of things in the code, that some variation on A is what was intended. Currently it's something like;

• The 32 Mute Groups are sets of tracks on Screen 0 that can be turned on together (turning all other tracks on Screen 0 and all other screens off.)

which seems weaker than it needs to be. The easiest (and what I am beginning to believe is the intent is;

• The 32 Mute Groups are an overlay on the active screen that turns a predetermined set of tracks on. All tracks on the active screen that are not in the mute group are turned off. All tracks on all other screens are also turned off.

This would allow you to use screens as play 'sets', mixing midi targets on the same screen. I tend to have drums on one screen, synth on another, etc., but under this model, I'd rearrange.

My book is being published by MakerMedia/O'Reilly in May. It's title is 'Make Fire: A DIY Guide to Awesome Propane Flame Effects'. It's a big fat reference and project book for building flame cannons, poofers, booshes, flambeaus, foundry torches, microcontroller shields for pattern fire, etc.. Most of my free time is spent playing with hardware, but I make my living in the software world. I build a lot of fire art for Maker Faire and the local Burning Man scene and have my Flame Effect Operator license, so I decided to write a book about it. Most people learn from hearsay and crappy web forums, so it was time to write a book on how to do it safely and properly. I started in August and have to turn in the last of it Jan 15., so almost all my free time has been spent on it.

But I've spent most of my advance from the publisher buying synths (MS-20 mini, microKorg, Volcas, etc.) I'm trying to run Sequencer64 on a Raspberry Pi (which works fine,) as the central midi clock and sequencer. I'm using a novation Launchpad as the controller so that I can mix beats, synth lines and stuff while I bang keys and twiddle knobs to make crazy noise.

Cheers, --Tim

On Sun, Dec 20, 2015 at 5:57 AM, C. Ahlstrom notifications@github.com wrote:

Thanks for the bug report! I've got it logged to investigate soon, but let me know what you find. Also, any info you can add about how to use this feature at a user level would help me.

I'm still beating on an event viewer (a list of all events) and editor, but it has proven a hell of a lot tricker to manage a viewing frame and insertions, deletions, etc.

As for NetBeans, I started using it when our work project started transitioning to Java. It's pretty cool, and I was able to get it to work with a Maven project. The Microsoft fans think VIsual Studio is the best IDE ever, but they are full of it -- it is bloated and awful, and I use it only for debugging our Windows-based code. But NetBeans (and Maven) run on Linux just fine. Most of the guys use Eclipse. If I get into the Java code (I'm the "C++ guy"), I'd probably set up eclim (Vim rulez).

Perhaps I could make the NetBeans setup and additional pack that the user could unpack to enable NetBeans support. Something to think about.

I really appreciate the feedback!

Chris

P.S. What book?

-------- Tim Deagan 20:48 Sat 19 Dec --------

Sorry to be so slow, all my free time is spent trying to get my upcoming book across its jan15 finish line. But (for deeply nerdy reasons,) I always spend a bunch of my christmas vacation time learning new source code, so I 've set up a Netbeans environment for sequencer64 (I have to confess I'm a Windows developer for a living and really gravitate towards IDEs. I've worked in linux for decades, but linux as an IDE breaks my heart.)

In any event, after some code surfing and debugging, it looks like a lot of the odd behavior I experience with mute groups is possibly because of the line: if ((i == m_playing_screen) && m_tracks_mute_state[j]) in perform::mute_group_tracks () isn't working as I imagined it should.

Gdb tells me that m_playing_screen never changes from 0 regardless of the m_screenset value. I believe this is why, no matter what screen you're on when you hit a mute group key, it ignores that screen and applies the mute group to the first screen.

I'll try i == m_screenset as an alternative sometime in the next few days. I just wanted to let you know I was still thinking about this.

cheers, --Tim

On Fri, Nov 27, 2015 at 1:29 PM, C. Ahlstrom notifications@github.com wrote:

Thanks! It is evolving.

As far as the mute-groups go, although I have cleaned up the way the code looks, that code should be mostly the same. I try to document what I finally figure out in the code, but there are still some gaps in my knowledge. Seq24 is really a lot "bigger" than it looks from the user-interface. I am taking baby steps, checking often that I haven't broken something.

Also, I have found some functionality that is only partly coded. For example, there's code to support copying SysEx into allocated memory and putting it in the event list, but the parser currently just skips SysEx and moves on to reading the next event.

There's some stuff I've barely touched other than to format the code nicely. The "fruity" mouse support is a good example.

Yeah, I started this project with the idea of adding a textual event view and migrating to the Gtkmm, but it's taken on a life of its own. I just found an SMF 0 file that the import code might not be reading correctly.

Oh, and you probably will find some mistakes in the document, so watch out for traps!

Chris

-------- Tim Deagan 10:17 Fri 27 Nov --------

Wow! Read through the doc, kudos on the incredible wealth of documentation!! Clearly I misunderstood the significance/function of the 'Set Playing Screenset' key. My midi map of the replace, snapshot and screen-set play keys still aren't giving me love, so I'll keep digging on that.

My compliments again on the doc, that's a huge undertaking and a tremendous boon.

--t

---

Reply to this email directly or view it on GitHub:

https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160185297

A vivid and creative mind characterizes you.

— Reply to this email directly or view it on GitHub < https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160193813> .

---

Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-166066418

Your fly might be open (but don't check it just now).

— Reply to this email directly or view it on GitHub https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-166112017 .

[TDeagan]

Cool. Making the change in perform::mute_group_tracks () from: if ((i == m_playing_screen) && m_tracks_mute_state[j]) to: if ((i == m_screenset) && m_tracks_mute_state[j])

makes the behavior (with light testing,) work as I expected:

• The 32 Mute Groups are an overlay on the active screen that turns a predetermined set of tracks on. All tracks on the active screen that are not in the mute group are turned off. All tracks on all other screens are also turned off.

I'll get a branch set up this week in git and set up a pull request so you can see the changes. I've also added a bunch of comments to it and perform::select_mute_group (int a_group) that may or may not be in the format you like. You can toss them if they don't work (I started in assembly language many decades ago and have trouble shaking the urge to comment every line.)

--Tim

On Sun, Dec 20, 2015 at 8:54 AM, Tim Deagan tim@deagan.net wrote:

I'll try diff'ing the current netbeans sequencer64 folder with a stock one when I get a chance, it looks like there is an nbproject folder in it that may be all that's needed to make it netbeans ready. I did have to run the .bootstrap, .config, make sequence in a terminal before I could get netbeans happy, but that's probably because I didn't spend enough time figuring out the prebuild config it wants. Once I ran the sequence manually, Netbeans picked everything up and seems to be working fine. Alas, all my meager linux dev over the years has either been in Python or QtCreator (I contributed to OpenSCAD for a while,) so the stock toolchain laughs at me.

If the mute functionality is supposed to work like it currently does (a la seq24,) then I'm baffled as to how to explain it concisely. It makes no sense to me. If what I mentioned above truly is a bug (going back into the seq24 code,) then I can picture a straightforward way to explain. But there are still some choices to make. A) Is mute an overlay on the playing screen's tracks? If so, what should happen to tracks playing on other screens? Ignored, same overlay applied to every screen? All other screens' tracks off? B) Is mute globally applied? If so, can you mix and match tracks from different screens?

I tend to think, from the size of things in the code, that some variation on A is what was intended. Currently it's something like;

• The 32 Mute Groups are sets of tracks on Screen 0 that can be turned on together (turning all other tracks on Screen 0 and all other screens off.)

which seems weaker than it needs to be. The easiest (and what I am beginning to believe is the intent is;

• The 32 Mute Groups are an overlay on the active screen that turns a predetermined set of tracks on. All tracks on the active screen that are not in the mute group are turned off. All tracks on all other screens are also turned off.

This would allow you to use screens as play 'sets', mixing midi targets on the same screen. I tend to have drums on one screen, synth on another, etc., but under this model, I'd rearrange.

My book is being published by MakerMedia/O'Reilly in May. It's title is 'Make Fire: A DIY Guide to Awesome Propane Flame Effects'. It's a big fat reference and project book for building flame cannons, poofers, booshes, flambeaus, foundry torches, microcontroller shields for pattern fire, etc.. Most of my free time is spent playing with hardware, but I make my living in the software world. I build a lot of fire art for Maker Faire and the local Burning Man scene and have my Flame Effect Operator license, so I decided to write a book about it. Most people learn from hearsay and crappy web forums, so it was time to write a book on how to do it safely and properly. I started in August and have to turn in the last of it Jan 15., so almost all my free time has been spent on it.

But I've spent most of my advance from the publisher buying synths (MS-20 mini, microKorg, Volcas, etc.) I'm trying to run Sequencer64 on a Raspberry Pi (which works fine,) as the central midi clock and sequencer. I'm using a novation Launchpad as the controller so that I can mix beats, synth lines and stuff while I bang keys and twiddle knobs to make crazy noise.

Cheers, --Tim

On Sun, Dec 20, 2015 at 5:57 AM, C. Ahlstrom notifications@github.com wrote:

Thanks for the bug report! I've got it logged to investigate soon, but let me know what you find. Also, any info you can add about how to use this feature at a user level would help me.

I'm still beating on an event viewer (a list of all events) and editor, but it has proven a hell of a lot tricker to manage a viewing frame and insertions, deletions, etc.

As for NetBeans, I started using it when our work project started transitioning to Java. It's pretty cool, and I was able to get it to work with a Maven project. The Microsoft fans think VIsual Studio is the best IDE ever, but they are full of it -- it is bloated and awful, and I use it only for debugging our Windows-based code. But NetBeans (and Maven) run on Linux just fine. Most of the guys use Eclipse. If I get into the Java code (I'm the "C++ guy"), I'd probably set up eclim (Vim rulez).

Perhaps I could make the NetBeans setup and additional pack that the user could unpack to enable NetBeans support. Something to think about.

I really appreciate the feedback!

Chris

P.S. What book?

-------- Tim Deagan 20:48 Sat 19 Dec --------

Sorry to be so slow, all my free time is spent trying to get my upcoming book across its jan15 finish line. But (for deeply nerdy reasons,) I always spend a bunch of my christmas vacation time learning new source code, so I 've set up a Netbeans environment for sequencer64 (I have to confess I'm a Windows developer for a living and really gravitate towards IDEs. I've worked in linux for decades, but linux as an IDE breaks my heart.)

In any event, after some code surfing and debugging, it looks like a lot of the odd behavior I experience with mute groups is possibly because of the line: if ((i == m_playing_screen) && m_tracks_mute_state[j]) in perform::mute_group_tracks () isn't working as I imagined it should.

Gdb tells me that m_playing_screen never changes from 0 regardless of the m_screenset value. I believe this is why, no matter what screen you're on when you hit a mute group key, it ignores that screen and applies the mute group to the first screen.

I'll try i == m_screenset as an alternative sometime in the next few days. I just wanted to let you know I was still thinking about this.

cheers, --Tim

On Fri, Nov 27, 2015 at 1:29 PM, C. Ahlstrom notifications@github.com wrote:

Thanks! It is evolving.

As far as the mute-groups go, although I have cleaned up the way the code looks, that code should be mostly the same. I try to document what I finally figure out in the code, but there are still some gaps in my knowledge. Seq24 is really a lot "bigger" than it looks from the user-interface. I am taking baby steps, checking often that I haven't broken something.

Also, I have found some functionality that is only partly coded. For example, there's code to support copying SysEx into allocated memory and putting it in the event list, but the parser currently just skips SysEx and moves on to reading the next event.

There's some stuff I've barely touched other than to format the code nicely. The "fruity" mouse support is a good example.

Yeah, I started this project with the idea of adding a textual event view and migrating to the Gtkmm, but it's taken on a life of its own. I just found an SMF 0 file that the import code might not be reading correctly.

Oh, and you probably will find some mistakes in the document, so watch out for traps!

Chris

-------- Tim Deagan 10:17 Fri 27 Nov --------

Wow! Read through the doc, kudos on the incredible wealth of documentation!! Clearly I misunderstood the significance/function of the 'Set Playing Screenset' key. My midi map of the replace, snapshot and screen-set play keys still aren't giving me love, so I'll keep digging on that.

My compliments again on the doc, that's a huge undertaking and a tremendous boon.

--t

---

Reply to this email directly or view it on GitHub:

https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160185297

A vivid and creative mind characterizes you.

— Reply to this email directly or view it on GitHub < https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-160193813

.

---

Reply to this email directly or view it on GitHub:

https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-166066418

Your fly might be open (but don't check it just now).

— Reply to this email directly or view it on GitHub https://github.com/ahlstromcj/sequencer64/issues/2#issuecomment-166112017 .