Piano World Home Page
I am proud to present to the PW community a pet project of mine: a small "set and forget" free application for automatic retrospective saving of live playing. The program is continuously running and listening to MIDI events and automatically saves midi files of your playing, split by silent intervals between takes.

The main goal of this application is to complement the VSTs standalone applications that commonly do not permit MIDI recording; with AutoSaveMIDI you don't need to use a DAW if you are only interested in simple MIDI recording. I took inspiration from a very useful feature of pianoteq and cantabile...

You can download the application for Windows here:

https://sites.google.com/view/autosavemidi/

[Linked Image]

Using AutoSaveMIDI is straight-forward, and the webpage of the project contains pertinent information about configuration. Hope you enjoy it...
It seems to work just fine. I wonder, though, why it uses so much CPU when it's just sitting idle. It uses 13% continuously. Only a video game uses more. That seems odd.
I believe it's because of the non CPU-optimized python MIDI libraries that I use, or the way python uses thread processes (or, most probably, because I am a crappy amateur programmer). I am sure that in C++ it would perform better, but this was a created just for the fun, and it turned out really ok, and in record time and I will not move it to another language (and the CPU usage does not affect my VST performance, although it causes a bit more fan activity in the laptop).
Well done, I'm a programmer myself, and I can see just from the screenshot that you put a lot of work into this app.
Great to see your project is launched. This is a great tool for me, so nice to see a tool like this present online! smile
I am using a beta version of this tool for some months and is really useful to be sure anything you play gets recorded without worrying about it. The automatic file saving, based on a configurable delay since last note was played, works wonderfully to separate pieces.

Thanks for this great tool!
Thanks all for the kind words. And a special "thank you" to David Lai and EB5AGV that were a stellar team of beta-testers that suffered through a series of software iterations while I was ironing out a few crinckles in the code. Some of their very good suggestions made their way to the final version.

Although we tried to test the application as best as we could, it was basically tested only on three keyboard models: Kawai VPC1 and 2 yamaha (one old CLP model, and a very basic PSR non-weighted model). Therefore, all feedback on AutoSaveMIDI user experience is greatly appreaciated.
Nice job vagfilm!

By the way, as a Windows tool, shouldn't the forwardslash (/) be a backslash (\) in the path selection box?

Kind regards,
James
x
This looks like a useful tool I would use if there was a version for Mac ๐Ÿ˜‰
Hello,

@vagfilm, Congratulations! And thumbs up to beta testers @EB5AGV and @David Lai.

A question: does AutoSaveMIDI also have a playback function for the recorded MIDI files? And/or how would AutoSaveMIDI pair up best with a playback tool, if one (like me) only uses standalone piano VSTis?

Cheers and happy recording,

HZ
Originally Posted by Kawai James
By the way, as a Windows tool, shouldn't the forwardslash (/) be a backslash (\) in the path selection box?
Windows natively supports both.
Originally Posted by Kawai James
Nice job vagfilm!
Thanks for the kind words, but have you tried it? Does it work well in newer Kawai pianos? (it is well tested in VPC1 but that is an old model soon to be replaced, correct? ๐Ÿ˜‰๐Ÿ˜‰๐Ÿ˜‰

Originally Posted by Kawai James
By the way, as a Windows tool, shouldn't the forwardslash (/) be a backslash (\) in the path selection box?
This was programmed in Python that follows its own rules for better integration of Win, Mac and Linux systems. You may see /, \, or \\ depending on the libraries used and the computer OS. I could do a "cosmetic" transformation: the internal value of the value would be whatever the computer wanted, but what was shown in the user interface was always changed to / for consistency, but quite frankly it is not worth the effort...

Originally Posted by CyberGene
This looks like a useful tool I would use if there was a version for Mac ๐Ÿ˜‰
As I said above, this was programmed in Python (and QT5 for the GUI) for two reasons: dead easy MIDI libraries for simple MIDI processing (that are a bit useless for more complex things and, as noted above, are heavily CPU dependent because they are always sampling the MIDI ports), and secondly for straightforward creation of Mac applications from the same code. I am only waiting for bug reports of this version before posting the Mac version smile
Thanks, appears to be useful but a bit too standalone for me.
Yes, i can record midi "as advertised" but only in stealth mode with no active player.

Tried to use it with Plogue Sforzando player the app is killed with the start button.
Checked with Pianoteq, same result.
Starting order and used keyboard do not matter.

-Rhodes74
I guess this is why the CPU usage is high ...
Originally Posted by vagfilm
This was programmed in Python ...
... dead easy MIDI libraries ...
... heavily CPU dependent because they are always sampling the MIDI ports.
Is the program sitting in-between the MIDI hardware (or USB) and whatever software is meant to use the MIDI signals? In that case you might want to add the ability to let the user set a velocity curve, so that the MIDI signals sent along to the software is altered in agreement with that velocity curve. That would be majorly useful.
Hello,

Originally Posted by Rhodes74
Tried to use it with Plogue Sforzando player the app is killed with the start button.
Checked with Pianoteq, same result.
Starting order and used keyboard do not matter.

-Rhodes74

I suspect this has something to do with MIDI ports being single-client under Windows. If you route your MIDI input to a virtual port (e.g. using the free loopMIDI tool), and then let your sforzando (or other VSTi) *and* @vagfilm's tool 'listen' to that virtual port, it may work fine. As said, I suspect.

Maybe @vagfilm can confirm this and provide further support.

Cheers and happy experimentations,

HZ
I use LoopMidi.

I have a velocity program (freeware) that reads MIDI data from my Presonus interface, and it writes the velocity-adjusted MIDI to a port in LoopMidi.
Kontakt reads from that LoopMidi port.
This is the velocity adjustment that Quasi wants.

This new AutoSaveMidi program also reads from that Presonus interface, no problems.

So both the auto-save and the velocity program read from the same MIDI input without issue.
I don't know why Rhodes74 has problems when using Plogue Sforzando.
I just thought of a business idea smile Create a small MIDI DIN dongle that will be inserted into the MIDI OUT of your piano and will have a micro SD card to save your MIDI performances. It can be powered from the MIDI IN port which has s 5V power, similar to the WIDI Master:
[Linked Image]
Actually the MIDI OUT has 5V power, so no need for the additional dongle, only a single MIDI OUT dongle is enough.
My lowly 2005-era Clav can record to a thumb drive in the MIDI-to-device socket.
Surely all the newer pianos can, too?
Originally Posted by MacMacMac
My lowly 2005-era Clav can record to a thumb drive in the MIDI-to-device socket.
Surely all the newer pianos can, too?

I am not aware of a digital piano that can automatically record MIDI all the time without you explicitly starting and stopping the recording. What model is that?
Cybrid, that is the one... And that may be feasible to do even on the arduino code (to send an automated start/stop recording to operate the app... Or send the messages in bulk with a delay that is non important for recording purposes... Otherwise the app is at full speed CPU even in idle).

But putting the app in a dongle it is next to impossible without a full OS (at least impossible to me).
I think even the most basic and compact Arduino is capable of intercepting the raw serial communication that happens on a single pin and record it. Actual MIDI file can be created later from that raw data by a software on the computer.
Originally Posted by QuasiUnaFantasia
Is the program sitting in-between the MIDI hardware (or USB) and whatever software is meant to use the MIDI signals? In that case you might want to add the ability to let the user set a velocity curve, so that the MIDI signals sent along to the software is altered in agreement with that velocity curve. That would be majorly useful.

I don't think that what you wrote is possible or desirable: the incoming MIDI signals are read simultaneously by the VST and by my application, and they don't talk to each other. It is easy to add a feature to have velocity curves that change the midi values as they enter. But if I do that, when you output that recorded MIDI file back to the VST, the VST will again apply a new velocity curve to the already changed velocity curve (so a value 100 that was changed to 110, is now 110 that is played as 121). So, it is not a good idea. The program should record midi as it is output by the digital piano and not as it is seen by the VST.

A workaround (depending if the VST has that possibility) is to make the VST output midi to a virtual port (LoopMIDI or akin) and record that on AutoSaveMIDI. I don't know if any standalone can output MIDI values...
Considering that your software solution is free, the choice is simple.
Originally Posted by vagfilm
But putting the app in a dongle it is next to impossible without a full OS (at least impossible to me).
Originally Posted by vagfilm
I am only waiting for bug reports of this version before posting the Mac version smile

excellent. looking forward to trying this. i have only actually used this feature a few times with PTQ to find something i played, but i was surprised by how much i like knowing that i have this feature there to draw on if necessary

will be interested to see how my aging computer handles the processing of this and garritan. i might look at setting up a virtual midi port as hz suggests if necessary

thanks vagfilm
Originally Posted by jackopiano
will be interested to see how my aging computer handles the processing of this and garritan. i might look at setting up a virtual midi port as hz suggests if necessary

thanks vagfilm

Will be waiting for your feedback on performance.

But if garritan "sees" your piano, then AutoSaveMIDI will also see it; there is no need for a virtual piano. Most probbaly it will automatically show up on the drop down choice of inputs.
Sorry for the late replies... I have to find a few minutes between work and family (well, this applies to everybody...)

Originally Posted by HZPiano
And thumbs up to beta testers @EB5AGV and @David Lai.

Indeed... The program core was basically finished when they tested it, but they were paramount in perfecting the UI and critical for setting up the installation and the configurations file. They found errors and potential user pitfalls that I never dreamed off. And they suggested a few features like the audio padding, the suffixes of the files, and maybe others that I am forgeting...

Originally Posted by HZPiano
does AutoSaveMIDI also have a playback function for the recorded MIDI files? And/or how would AutoSaveMIDI pair up best with a playback tool, if one (like me) only uses standalone piano VSTis?

Playback of MIDI files? That is a daunting task that I will not even attempt... You will need to pair it with a MIDI player.
Now comes the problem: I still have not found the perfect MIDI player for windows (and I am open to good suggestions).
For simple things, you just open the files on Windows Media Player and it plays using some MIDI synthesizer. Good to fast listening and browsing of files. Downsides: WMP cannot output to a MIDI port to feed a VST and you don't have any kind of mixer if you have that...
The best free MIDI player I am aware is a Karaoke player:VanBasko. You can set MIDI output, it has a good channel mixer, velocity control, fast seek through the file, and even a piano window with blinking keys. Downside: it is geared to karaoke and it has probably the ugliest user interface in the history of computers.
My MIDI player: synthesia !!! The best thing for MIDI since sliced bread. Great folder management, perfect and thorough setting of MIDI inputs and outputs, very good player and mixer, timeline seeker, easy setting of loops, AUTOMATIC DISPLAY OF SCORE (ok, not sibelius, but it is automatic!!!), and you can hide the notes waterfall.
Getting back to the issue of velocity curves brought up by QuasiUnaFantasia, I remind you that one useful feature of AutoSaveMIDI is seeting up a file suffix. If you are playing a particular VST with a particular velocity curve, you can define a suffix such as "-VSTname_VelCurve1" and all files will be easily identifiable. If you need to render that particular MIDI to audio, you simply need to put it through the appropriate VST and velocity curve... You can define and memorize 10 different suffixes and I can easily increase that to a larger number if a number of users find it convenient (but it will clutter the user interface).
Originally Posted by Rhodes74
Yes, i can record midi "as advertised" but only in stealth mode with no active player.
Tried to use it with Plogue Sforzando player the app is killed with the start button.
Checked with Pianoteq, same result. Starting order and used keyboard do not matter.

That is unexpected (the program was heavily tested using Pianoteq demo) and I need more information about the crash to debug the error.
If the crash occurs when you hit the START button, the most probable cause for the crash is an error in the definition of the folder where to put the recordings. The program should test its viability and give a warning that it cannot access that particular folder, but it may occur nonetheless.
Try setting beforehand an empty folder in which to place the recordings, and do be sure it works, put it in the root. Create a folder inside "C" called "midi recordings". Then launch AutoSaveMIDI and in the user interface browse and select that folder. Just to be sure click on another button (for example, increase the split interval by one second...). Then click on START and see if it works.
Originally Posted by CyberGene
I just thought of a business idea smile Create a small MIDI DIN dongle that will be inserted into the MIDI OUT of your piano and will have a micro SD card to save your MIDI performances. It can be powered from the MIDI IN port which has s 5V power

I suspect it would be hard to set/persist the date/time on such a device, so it'd be difficult to sort/order the recordings other than by name?

Lack of date/time on DPs is another pet peeve of mine. It would be so helpful for saving MIDI/WAV/MP3 files.

Vagfilm, amazing work here! Looking forward to a Mac version. Is there any easy way to tag something so that you can leave it recording forever, but if you have a particularly nice take you can hit a key combo or button and "flag" or "star" it to find later?
Thanks HZ & vagfilm!

I installed loopmidi and added a port. I can chose this port in player and autosavemidi but no data comes through.
The savepath is valid and i can record with autosavemidi alone but is a blindflight without audio.

-Rhodes74
Hi Rhodes74: in most cases YOU DON'T need a virtual port like loopmidi (these are only needed when the midi signals come from a source internal to the computer).

Walk me through your setup... What piano are you using? When playing do you use the digital piano sound or an external VST? Do you normally connect the piano to the computer through usb? What are the options for MIDI INPUT that show up on AutoSaveMIDI when you connect it to the computer?

I am unfamiliar with Sforzando. What input were you using to Sforzando before you installed AutoSaveMIDI? You don't need to output midi from sforzando to AutoSaveMIDI... You feed midi from the keyboard to AutoSaveMIDI.
Hello,

@Rhodes74 and @vagfilm, The single-clientness of Windows' MIDI ports (which are used automatically when a piano and/or other MIDI input device are hooked up through USB and those devices don't have proprietary drivers) is something I recently became aware of.

For instance I wanted to run two instances of sforzando in parallel, or another VST and sforzando, or a VST and midiOX at the same time, and so on. When setting a second 'something' to listen to a Windows port that is already listened to by another 'something', error messages occur and/or things just don't work as expected.

A virtual port like those that loopMIDI creates is multi-client so doesn't have these limitations/problems.

@Rhodes74, You got no data coming through because one more step is needed: to link the incoming MIDI (through that automatic Windows port) to the loopMIDI port. This can be done by using the free midiOX tool (which is quite useful in many ways, by the way). In that tool, there is an option to 'draw' a line from the incoming port to the loopMIDI port, after telling midiOX in a setup menu which ports you want available in midiOX.

Whether that solves the AutoSaveMIDI crash remains to be seen of course, but this is what I can offer based on my initial hunch.

Cheers and happy MIDI channeling,

HZ

PS Maybe this gives a further bit of help:

I understand the problem. But I don't have this problem, so I don't know why someone else might.

I can run multiple VST hosts that simultaneously read from the same MIDI port.

I have had as many as three programs reading simultaneously from the Presonus MIDI port, and as many as two reading from a LoopMidi port.

No problems. This is on Windows 10.

Perhaps my Presonus MIDI driver "plays nice", and the LoopMidi port software "plays nice" ... while some other drivers do not?
HZPiano, in my very short experience i did not encounter any problem with 2 programs accessing the same midi port (physical or virtual). You and Rodhes74 report that problem and you are both using sforzando, so I suspect that to be the culprit.

The beta testers were running AutoSaveMIDI with VSL, garritan, VILabs, and Kontakt standalones, or even recording at the same time to reaper or cubase.

Again, I suggest to troubleshoot it step by step, instead of installing midiOX and midiloop, which can create a new level of problems for the unfamiliar user. Do you need loopMidi to run sforzando with midi signals from a piano?
Originally Posted by MacMacMac
It seems to work just fine. I wonder, though, why it uses so much CPU when it's just sitting idle. It uses 13% continuously. Only a video game uses more. That seems odd.
This behaviour means that application is continuously and actively waiting for MIDI events in a loop. The CPU usage is the same regardless of whether the application is actively waiting or if it is actually processing the incoming MIDI events. Since MIDI events are produced at an extremely low frequency, the app is mostly wasting CPU cycles and producing heat. The CPU usage percentage depends on the number of cores of your CPU. This application is single-threaded and therefore will be bound to one single core of the CPU. So, you get ~12.5% of CPU usage because your CPU has 8 cores. You would get ~25% usage if you had a 4-core CPU.

Originally Posted by vagfilm
I believe it's because of the non CPU-optimized python MIDI libraries that I use, or the way python uses thread processes (or, most probably, because I am a crappy amateur programmer). I am sure that in C++ it would perform better, but this was a created just for the fun, and it turned out really ok, and in record time and I will not move it to another language (and the CPU usage does not affect my VST performance, although it causes a bit more fan activity in the laptop).
Thank you for the app! This is independent of the programming language you are using. You need to suspend the app, otherwise if you keep the active waiting the app will always use 100% of CPU.
An option is that you suspend app with a time.sleep() function. The MIDI transfer rate is 31.25 Kbit/s, roughly 4 Kbyte/s. So, instead of processing one MIDI event at the time I would do the following:
Code
loop
  time.sleep(X milliseconds) 
  for event in midi_events <- multiple events can be received while suspended
       process each event 
end loop

You will need to find out for how long you can suspend (sleep) the app without starting to lose data. As said above, you will receive at most 4KB worth of MIDI events per second. You need to check what is the maximum size of the buffer of the MIDI library you are using. I have used MIDI libraries (non in Python) that can easily buffer several KBs of MIDI data. Check the documentation or code of the library you are using. But you will most certainly be able to suspend the app at least for 100-200 ms each time. This will reduce the CPU usage to near zero. Keep on the good work!
Sforzando is a player for soundfont and .sf2 samples, AFAIK quite similar to the garritan player. Same behaviour for pianoteq. For testing i had an Irig37pro is connected via USB, it shows up in the player and in autosavemidi as the only option. There is no ASIO driver because audio is routed to a soundcraft mixer.

Whatever it is, in my configuration the MIDI routing needs help. Running loopmidi and now midiox solved the problem.

Many thanks to vagfilm for providing and HZPiano for help running this nifty tool!

(And of course a feature request: How about a click-open for the storage folder?)

-Rhodes74
Hello,

@MacMacMac, If your MIDI comes in through the DIN-MIDI on your PreSonus interface, I reckon things indeed work neater than the automatic Windows ports. PreSonus may use proprietary drivers for that instead of leaving it to Windows.

@vagfilm, It might be that the current Windows 10 has a better MIDI implementation. My single-client limitations were found on Windows 7 Pro, and were solved using the virtual port routing. Not sforzando-related.

Cheers and happy developing,

HZ

PS Still curious about the playback question I asked earlier. Cheers!
Originally Posted by HZPiano
PS Still curious about the playback question I asked earlier. Cheers!

I answered that in post #3160579 above
Originally Posted by Rhodes74
Running loopmidi and now midiox solved the problem.

-Rhodes74

Lovely! I hope that is a useful result for @vagfilm as well.

Cheers and happy nifty tooling,

HZ
Originally Posted by Rhodes74
For testing i had an Irig37pro is connected via USB, it shows up in the player and in autosavemidi as the only option.
Running loopmidi and now midiox solved the problem.
So it is working now... Good to hear... There is a workaround if necessary. Glad HZPiano was able to help.

Originally Posted by Rhodes74
And of course a feature request: How about a click-open for the storage folder?

I could add that (in fact if you click on the option for setting up the folder, it will open windows explorer. Currently, it will open in the program folder instead of the recordings folder - something to change to version 1.02), but it will clutter the UI and could lead to users messing up the recording folder location because they can by mistake point the recordings to 2 different folders... Don't you prefer to simply create a shortcut on the desktop to the recordings folder? wink
Hello,

Originally Posted by vagfilm
Originally Posted by HZPiano
PS Still curious about the playback question I asked earlier. Cheers!

I answered that in post #3160579 above

Sorry I missed that, thanks!

I didn't mean for you to integrate a synthesizer into your tool, but a simple (I know, simple is relative here!) way to browse/manage the recorded files (perhaps with some attributes such as the 'stars'/flags that @gombessa suggests). Then, a Play button that sends each MIDI message from a recorded file, timed from its timestamp, to a virtual port that the user's favorite standalone VST (or DAW) listens to; or sent back to the piano if the user wants to use the piano's internal sound generator instead of a VST.

That way, the user gets feedback on her/his playing that is indistinguishable from the original playing (provided the same VST/internal sounds and related settings are used as while recording).

Just tossing ideas, again, thumbs up for the work!

Cheers and happy developing,

HZ
Originally Posted by acdp
An option is that you suspend app with a time.sleep() function.

Thanks for the suggestion. To be honest, this CPU thing only came up a couple of weeks ago, because I was unaware of it until then. I thought about adding a sleep in the thread loop as you suggest, but was afraid that it would cause a problem in the timestamping of the MIDI messages. MIDI messages are timestamped by the receiver not by the sender.

In addition, the MIDI python library that I use cannot handle multiports (or it may, but I was unable to make it work as intended), so I had to cascade up to 3 threads of single MIDI ports, because some users may need up to 3 midi inputs (keyboard(s), external pedal, CC controller). So, I would need to add a sleep to each thread, that would have different timings depending on the number of active threads. I will start testing it, but currently don't have the free time to do that.

I am biomedical researcher in academia... My programming experience is on data processing (python, matlab) heavy on data crunching and files management, but where UI and realtime processing does not exist (you program, test, hit "run" and collect the output file in a couple of hours). And even that is done nowadays by my PhD students... This was my first venture into the realm of QT5 and UI multithreading. I had a lot of fun that helped maintain my sanity while the lab was half-shut and the students haad their thesis on hold. Depressing times that had profound consequences...
Originally Posted by vagfilm
I could add that (in fact if you click on the option for setting up the folder, it will open windows explorer.

Yes, i found that already and it points to the storage folder, just not opening it in explorer. But i see, i can right-click in the file list to open an independent window. Close to good enough!

Originally Posted by HZPiano
PS Still curious about the playback question I asked earlier. Cheers!

Also close: You can use soundfont midi player connected to sforzando and load the midi files in a playlist.
Fast access and timestamp in the filenames.

-Rhodes74
Originally Posted by HZPiano
I didn't mean for you to integrate a synthesizer into your tool, but a simple (I know, simple is relative here!) way to browse/manage the recorded files (perhaps with some attributes such as the 'stars'/flags that @gombessa suggests). Then, a Play button that sends each MIDI message from a recorded file, timed from its timestamp, to a virtual port that the user's favorite standalone VST (or DAW) listens to; or sent back to the piano if the user wants to use the piano's internal sound generator instead of a VST.

That way, the user gets feedback on her/his playing that is indistinguishable from the original playing (provided the same VST/internal sounds and related settings are used as while recording).

As I told before, that is not simple, and there are better tools out there that do exactly that. It would be very easy to playback a MIDI file from within AutoSaveMIDI through the VST standalone that is active. But it will only play from the beggining and you cannot do random access with a slider to a different timepoint in the recording. MIDI messages are incremental (so, relative, not absolute) and measured in ticks, not in time. I don't know which message will be played at time 33.0, unless I sum up all messages until I reach 33.0. Thus, before playback I would need to create a table that would have, for each MIDI message, it's calculated absolute timestamp based on the playback speed that was selected. And whenever the user changed the playback speed, the table would need to be updated. I am sure that there are MIDI libraries (in c++) that already have all this implemented, but I am not aware of a simple way to do that in Python.

Bottomline: what you suggested already exists. You can use the free VanBasko midi player, or the paid Synthesia, select in either MidiLoop as the output, make them the default handlers of .mid files, and everytime you click on a midi file, it will launch the player that outputs through the VST. No need to reinvent the wheel.
Well... Rhodes74 just mentioned "soundfont midi player" which I browsed and it seems to be even better than VanBasko (and free as well). Have to install that, although I prefer the convenience of the paid Synthesia.
Originally Posted by acdp
An option is that you suspend app with a time.sleep() function.

Wow... There is nothing like trying. I put a 1ms sleep() in the main loop that controls the cascade and the CPU usage is now less than 1%... Don't seem to have any dropped notes (I test with an intensive midi file played back at 300 bpm), but will have to run more thorough testing.

Thanks for pushing me to try it. I did not believe it would solve the issue... It was crappy programming afterall smile
Hello,

Originally Posted by vagfilm
No need to reinvent the wheel.

All for that! Thank you for your further explanation.

Originally Posted by vagfilm
Well... Rhodes74 just mentioned "soundfont midi player" which I browsed and it seems to be even better than VanBasko (and free as well).

That sounds like a lovely option. Thanks @Rhodes74 and @vagfilm!

Cheers and happy MIDI reflections,

HZ
Originally Posted by vagfilm
Originally Posted by acdp
An option is that you suspend app with a time.sleep() function.

Wow... There is nothing like trying. I put a 1ms sleep() in the main loop that controls the cascade and the CPU usage is now less than 1%... Don't seem to have any dropped notes (I test with an intensive midi file played back at 300 bpm), but will have to run more thorough testing.

Thanks for pushing me to try it. I did not believe it would solve the issue... It was crappy programming afterall smile

Excellent! The MIDI data rate is very low even at the maximum MIDI 1.0 rate. At maximum rate it allows for ~1000 MIDI events/second. So, this limit will not be reached when recording a "normal" human performance, which is the primary use case of your app. Generating such amount of events requires computer generated messages or chaining multiple MIDI devices together. (These limitations, as well as the timing limitations of with MIDI 1, are now greatly improved in the new MIDI 2).

Anyway, your application was most of the time doing nothing but looping around, hence the very high CPU utilization. The same would happen with a similar loop in C++ or Java. Adding a short sleep to the loop allows the operating system to "pre-empt" (suspend) the application drastically reducing CPU utilization. You need to check if the sleep/suspend works correctly with the different threads (it should). As a simpler alternative in a future version of the app, you might be consider scanning the multiple ports sequentially in the in same loop and in a single thread. This would simplify the code and avoid potential issues due to multithreading. Happy coding!
Originally Posted by HZPiano
Hello,

Originally Posted by vagfilm
No need to reinvent the wheel.

All for that! Thank you for your further explanation.

Originally Posted by vagfilm
Well... Rhodes74 just mentioned "soundfont midi player" which I browsed and it seems to be even better than VanBasko (and free as well).

That sounds like a lovely option. Thanks @Rhodes74 and @vagfilm!

Cheers and happy MIDI reflections,


HZ

You might want to a look as well at VirtualMIDISynth . This is not a MIDI player but a MIDI synthesizer that allows installing sample-based sound fonts to render the MIDI files. The FluidR3_GM (available on the the link above) is quite good for general MIDI instruments. You can also add a couple of sound fonts with improved samples for classical music.
I wonder how VST hosts handle this? Surely they don't poll the MIDI ports!

There must be a way to "hang a read" on a port (some really old terminology there) ...
... and then either block while waiting for MIDI data (perfect for a threaded app) ...
... or instead just register a callback to handle MIDI data when it arrives.
I am almost sure it is based on c++ callback functions.
Originally Posted by vagfilm
Originally Posted by acdp
An option is that you suspend app with a time.sleep() function.

Wow... There is nothing like trying. I put a 1ms sleep() in the main loop that controls the cascade and the CPU usage is now less than 1%... Don't seem to have any dropped notes (I test with an intensive midi file played back at 300 bpm), but will have to run more thorough testing.

Thanks for pushing me to try it. I did not believe it would solve the issue... It was crappy programming afterall smile

Please, let us know if you release a new version with that modification implemented. It will help on lesser computers

Thanks!

Jose
I will test over the weekend and update afterwards, and post here.
Originally Posted by vagfilm
I will test over the weekend and update afterwards, and post here.

Thanks Vasco! thumb
Thanks. Nice work.
Originally Posted by vagfilm
I will test over the weekend and update afterwards, and post here.
At this moment the app has been downloaded by 20 something users. Apart from the problem reported and solved with a workaround by Rhodes74 (and I am not sure if it also happened with HZPiano...), and the CPU consumption that I may be able to solve, for all the others that have been posting in this thread, the app is running well? No increased latency on VSTs? No dropped notes? Pedalling correctly detected? The ones using onboard piano engines, no problems in midi output to record? No bugs on installation?

All feedback on installation, setting up, and actual performance is appreciated.

BTW, no antiviral complaints during download or installation?
Hello,

@vagfilm, I didn't (yet) download your tool. I just read this thread with great interest and was glad to be able to help -- from nothing more than a hunch I got when reading Rhodes74's start-and-crash problem.

Cheers and keep up the good work!

HZ
Thanks...
A quick post to inform that I have run some tests with the sleep function in the main loop set at of 20 microseconds, and not only it reduces drastically CPU use (less than 1%) but it improves MIDI accuracy !!! I use a perfectly quantized mock midi test file of 480bpm to stress test the program: without the sleep() and at full CPU usage, a replay of 256 notes per second does not drop any notes, but simultaneous notes drift significantly; when I set a very short sleep(), the drift is dratically reduced. I tested a few timings for the sleep() and found that 20 microseconds is a good compromise for not stressing the CPU while good MIDI accuracy is maintained. I will release an updated version 1.02 tomorrow.
Great news, thanks!. Since I was aware of the CPU usage while beta testing, I was somewhat obsessed with it. Now the new version will help using the software without monitoring CPU in background smile
Hello,

Nice work, @vagfilm!

Cheers and happy optimizations,

HZ
Originally Posted by vagfilm
Originally Posted by Rhodes74
Yes, i can record midi "as advertised" but only in stealth mode with no active player.
Tried to use it with Plogue Sforzando player the app is killed with the start button.
Checked with Pianoteq, same result. Starting order and used keyboard do not matter.

That is unexpected (the program was heavily tested using Pianoteq demo) . . .

Interesting that you tested using the Pianoteq app. I don't think it's been mentioned yet in this thread, but I'm not sure people using Pianoteq have any need for this add-on utility. The Pianoteq app already has this "save everything that's played" midi recording functionality built-in. I think many people use Pianoteq and aren't aware of this, but your playing is by default recorded behind the scenes to midi files by Pianoteq itself. Those files can be found using "File, Recently Played on the Keyboard" menu choice, and then selected to play using Pianoteq's built-in midi player. (There are user settings, I believe, to control how long Pianoteq retains these files and where they are stored, perhaps more.)

I think this is all it says about this in the Pianoteq manual:
======================
"2.9.3. Brilliant performance lost?

At any time, you can retrieve your recent performances via File โ–บ Recently played on the keyboard. Particularly useful when after a brilliant performance you think โ€œtoo bad I didnโ€™t record thisโ€! Well, Pianoteq did it for you: just load the latest Recently played on the keyboard and save/export it to a regular MIDI/AUDIO file. Itโ€™s as simple as that!

For less recent performances, a MIDI Archiver is available, access to its settings at the bottom of the Recently played on the keyboard menu."
======================
Hi... I used pianoteq during testing because:
1. I tested with ALL VSTs I have at hand. For pianoteq I have the demo...
2. The only purpose of that testing was to check if starting the recording with AutoSaveMIDI would affect VST playability. Remember... My app can be used without a VST while playing with the internal sounds: you connect to a computer, play with the built-in sound and record externally. No possibility of decreased performance in that case.
3. As you mentioned, pianoteq also has automatic recording; thus I could compare the output of both midi files;
4. Pianoteq has a useful midi monitor to check for incoming midi messages.

All in all, I love pianoteq, although not particularly convinced by its tone. If I had bought pianoteq, I might never gone through the effort of creating my own recording app... So, all is well.
Originally Posted by hes
I don't think it's been mentioned yet in this thread, but I'm not sure people using Pianoteq have any need for this add-on utility. The Pianoteq app already has this "save everything that's played" midi recording functionality built-in.

Thanks for the comment. In fact, in my first post I said that this feature of Pianoteq was my inspiration.

I think that once you try it, you will appreciate a few aspects of my app that do not exist in Pianoteq: automatic splitting defined by the user, definition of minimal length, possibikity of adding id suffixes to the files, audio padding, and soon to be implemmented way to score a recording immediately after play for easier sorting btween takes.
Hi all:

VERSION 1.02 WITH LOW CPU USAGE IS UP AND RUNNING !!!

The link for the webpage remains the same:

https://sites.google.com/view/autosavemidi/

and you can always access the webpage of the project by clicking on the blue letters of the version in the GUI (where it pompously says "Cajal Software" which is obviously a ghost software company...).

No need to uninstall the previous version. It should overwrite the exe file, while maintaining the settings registry and the recordings folder.

Let me know if performance improved.

BTW, I also changed the browsing of the recordings folder... When you click on the button for changing the folder, it will (hopefully) take you to the current folder instead of the root folder of the program...
Sorry... Forgot to update the link on the webpage. It should be correct now.
Working perfectly and with LOTS less resources! smile wow

I have checked just before the previous version (v 1.01), once Windows had stabilyzed. From 2-4% CPU use it went to 16-18%

Now, v 1.02 just adds 1% or so, as you commented. GREAT!!! thumb
Kudos to acdp that convinced me to try the sleep() on the main loop. In my naivete I thought it would disrupt the midi timings and that the problem lied elsewhere... Worked like a charm...
It's kinda sad this doesn't exist for Linux, because Windows Machines require much more power.
Well... In fact it does exist to Linux but it has not been tested and for that reason it is not yet publically available for download (it was written in Python, so it is easily compilable to linux, Macs and Win). If interested, send me a PM, and you will be officially named "beta-tester" of the linux version...
BTW, the same thing applies to macOS. If you are interested in testing the mac version before public release, PM me and will send you the apple version for you to try. I am a windows-only person, and need third person help for beta-testing stability and functionality. Thanks.
I love this version, stable and works like a charm. Successfully updated. smile Thank you for giving us such a simple tool to record the midi data!!!
David... Thanks for the kind words... I still want to add the possibility of rating the playing immediately after playing (through key combinations) so that each take can be marked as "good" or "bad" for future review (or deletion).

I have another tool for complete custom velocity curves... It is still in alpha stage because I have to think about how to make it more user friendly, but you can set mapping to any MIDI parameter: note-on velocity, note-off velocity, half pedalling ranges, dynamic range (ie, changes in volume coupled with the velocity: low velocities can have a small decrease in volume, and high velocities can have an increase in volume, not changing the timbre), and mappings per key. Most VSTs now have these mappings, but this is a universal tool. I will send you when it is polished.
Originally Posted by vagfilm
David... Thanks for the kind words... I still want to add the possibility of rating the playing immediately after playing (through key combinations) so that each take can be marked as "good" or "bad" for future review (or deletion).

I have another tool for complete custom velocity curves... It is still in alpha stage because I have to think about how to make it more user friendly, but you can set mapping to any MIDI parameter: note-on velocity, note-off velocity, half pedalling ranges, dynamic range (ie, changes in volume coupled with the velocity: low velocities can have a small decrease in volume, and high velocities can have an increase in volume, not changing the timbre), and mappings per key. Most VSTs now have these mappings, but this is a universal tool. I will send you when it is polished.


That's wonderful!!! Wow, you have great ideas in expanding your programing skills. I admire you!!!

Thank you for including me in your testers team. smile
© Piano World Piano & Digital Piano Forums