Consolidate?

[john-]

When I started making my changes to my fork of ham2mon I arbitrarily based it on a fork with the most recent activity. However, it is clear that your fork has a lot of good stuff in it and would probably have been a better starting point.

Furthermore, your fork has two changes that I previously made that were never merged into the original ham2mon (thanks!). Since that time I have done these changes slightly differently but hopefully better.

My issues list has all the changes I have made to the original ham2mon: my changes. All but one of these are merged into my master.

My primary use case is using ham2mon as an "embedded" application that requires only intermittent access via the curses gui. The user primarily interacts with the the recorded audio through a separate Web interface. This is first step of a rewrite of something I have been using for a few years.

Anyway, I am really interested in the changes you made for logging and anything that improves performance. I am exploring adding a Websocket interface (not documented yet). As part of that one of my changes incorporated a partial move to asyncio.

I am a Python novice so am interested in your thoughts on 1) whether it makes sense to merge these two efforts and 2) how to go about doing that.

If it doesn't make sense to fully merge them I will figure out how to cherry pick from your fork as there is some good stuff in it.

[john-]

I started the merge from your fork.

[lordmorgul]

Hi John, I am open to merging and work combined. There is another recent cobtrib also with good ideas.

There are several known use cases we should see about making valid at once with top level mode swiches. I will follow up with an attempt at description of those, including yours as one, mine as one, original intent as third, possible fourth from other repo.

I have had no tine to finish testing and fix the CTCSS filteribg branch.
The priority channel approach is poor, but there is a better approach in other repo to merge.
I tried on MacOS machine recently and minor fix for that not yet in my master.

[john-]

Sounds good. In the next few days I should be done with a branch that should streamline the merge into another repo if that is the path we take.

I can start discussions for the couple of things that probably need to be decided on as part of that merge.

[john-]

Currently none of the features I add based on my repository can be easily merged into yours. I am not a git expert but it seems like it may be due to some fundamental differences between them.

In the past I merged everything in your master into my master branch. I think this was done completely as that was my intent. I don't think there is anything in your master branch that is not in mine. If there is it can easily be added.

What is the next step here? Even with that work the differences still seem to hinder easily merging pull requests.

Unless you have a better solution please review the following with the idea that you overwrite your master with my master branch. It seems to me going the other way doesn't gain anything.

Some of the changes I have in my repository that are not in yours:

• asyncio changes: It seems like this is something that will development in the future. For example, for testing purposes I added a simple timer in the Scanner class that will asynchronously run arbitrary code without using the scan_cycle logic. Maybe wide range scanning can use something like this to change center frequency. Currently it also allows for dynamic resizing of the curses window. However, If you have a reason to drop asyncio support let me know. This may be the change that is making our merges non-trivial.
• Python 3 only support. Although there is still some Python 2 support in there I know Python 2 is broken in my fork.
• Audio classification. If you don't feel comfortable with what I propose this could be merged into your repository.

There are some features in my branch done differently than in yours. For example, min/max recording length. I think users could make this change pretty easily.

There are some future things but I am holding off merging until we can streamline things. This includes move to python argparse and improvements to range lockouts.

Let me know what you think.