Question: How do I disable/enable the metronome in the recorder example

[goofy2k]

The metronome component is not explicitly set in the example. Yet it plays! I do not see handles for switching this on/off in sequencer, recorder, advancedsequencer.

[ncassetta]

Yes, the metronome (and the count-in measure) are automatic and cannot be turned off. The metronome is triggered in MIDIRecorder::Start () in the line recorder.cpp: 281 (by the method SetSeqNotifier() ). If you want to disable it you can comment thate line, and the corresponding line 307 which calls ResetSeqNotifier()). It is possible to introduce the disabling of the metronome as a new feature

[goofy2k]

Thanks, yes of course that would be a nice new feature.

Of course I can block the involved channel in my synth. The reason to put it off now is that I want to get rid of logs for the metronome notes. I want to get a "clean" log for other notes as I need to analyze where in the chain of events I loose messages now and then. Especially in the case of "note off" messages this is annoying ;-)

I supect that reading out of the "raw message input buffer" sometimes misses an event. Could be due to poor code around my HardwareMsgIn or so....

Op vr 14 jan. 2022 14:54 schreef Nicola Cassetta @.***>:

Yes, the metronome (and the count-in measure) are automatic and cannot be turned off. The metronome is triggered in MIDIRecorder::Start () in the line recorder.cpp: 281 (by the method SetSeqNotifier() ). If you want to disable it you can comment thate line, and the corresponding line 307 which calls ResetSeqNotifier()). It is possible to introduce the disabling of the metronome as a new feature

— Reply to this email directly, view it on GitHub https://github.com/ncassetta/NiCMidi/issues/11#issuecomment-1013137690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGII3TRDHJBGRSWPUAUOZV3UWATLBANCNFSM5L3USEFQ . You are receiving this because you authored the thread.Message ID: @.***>

[goofy2k]

I am currently working on the UI input side for the synth. So I am silent for a while here. This concerns accepting e.g. program change messages etc. This will take me a while. After that, I will return to using those in your lib.

[goofy2k]

I managed to record a sequence of notes over different channels now. The recording is a correct replicate of what I played. I still have to deal with missing keyOff's (and probably also keyOn's but these are harder to recognize. This is something that I probably have to solve in my handling of HardwareMsgIn.

As all basic examples now operate pretty OK, this is probably a right moment to consolidate and have a good look at changes that I made to your lib files. I'll have to judge which ones of them are really required for successful usage and which ones prove to be obsolete. I will report to you on that.

While writing this, I realize that the many logs that I added are pretty essential to me for further development of the application. I am not very well into version and branch management in Github. Do you have a suggestion how to keep my adaptations and still be able to absorb your commits?

My purpose with this is to get a situation where I can hopefully simply use your main branch and follow future improvements.

I propose to close the current issue.

[ncassetta]

I'm happy with your progress. I also don't know github to a very thorough level. It seems to me that you could put your code in another branch, update the master and then do the manual merge by manually resolving all the conflicts, but that's something I've never done. However today I have published version 1.1.0 where I think I have also fixed the bugs due to the wrong parameter types in many functions. This should be a stable version and I think you (after having merged it with your code) may be using this for quite some time (hoping not to find any more bugs!)

[ncassetta]

I found this: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/merging-an-upstream-repository-into-your-fork. Probably you should fork my repo, make your changes and then pull the upgrades resolving the conflicts.

[goofy2k]

I'll give this a try coming week. Thanks!

Op zo 23 jan. 2022 12:42 schreef Nicola Cassetta @.***>:

I found this: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/merging-an-upstream-repository-into-your-fork. Probably you should fork my repo, make your changes and then pull the upgrades resolving the conflicts.

— Reply to this email directly, view it on GitHub https://github.com/ncassetta/NiCMidi/issues/11#issuecomment-1019466779, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGII3TVL2BK65CIPENGVUG3UXPSRFANCNFSM5L3USEFQ . You are receiving this because you authored the thread.Message ID: @.***>

[goofy2k]

Most of my adaptations are probably logs. I am currently aware of two important adaptations: 1) the use of MQTT inport and Nimble outport. I should modify these such that they can be used like you use the RtMidi lib. 2) the use of a freeRTOS based timer rather than a thread based one.

The second is probably the most "entangled" adaptation. Ifffff you ever want to make your lib to work for ESP32, it would be useful if you absorb that into your timer.cpp/.h. ESP32 and it's successors are probably a strongly upcoming target.

Op zo 23 jan. 2022 12:42 schreef Nicola Cassetta @.***>:

I found this: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/merging-an-upstream-repository-into-your-fork. Probably you should fork my repo, make your changes and then pull the upgrades resolving the conflicts.

— Reply to this email directly, view it on GitHub https://github.com/ncassetta/NiCMidi/issues/11#issuecomment-1019466779, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGII3TVL2BK65CIPENGVUG3UXPSRFANCNFSM5L3USEFQ . You are receiving this because you authored the thread.Message ID: @.***>