v1.4.1 "The 1.4 version that actually works"

This release brings the rework a step closer to completion. It fixes many small problems v1.4.0 had with running the Webserver, especially the midi part.

Now the Midi-Input listens to Midi-start and Midi-stop messages to trigger the rec status.

The attached .exe should theoretically work, but it currently has some weird issues with some workstations. I recommend downloading the zip and following the Readme for the installation. You don't need to compile the app again but may need to install some dependencies.

Updates:

• Listener for Midi-Input works now.
• ErrorHandling, when Midi-Output is deactivated or not available
• Spelling-Errors fixed
• HTTP-Get has a now handled edge-case
• compiling with pkg from yao-pkg now works again
• update and extend documentation

What's Changed

• Fixes for Midi-I/O and compiling by @ScheerleJo in #8

Full Changelog: v1.4.0...v1.4.1

v1.4.0

"I looked at v1.3.2.2 of HTTP2MIDI and was afraid of it.
As I kept looking and going through my code, I wondered more and more how this piece of garbage had ever worked.

So I decided to rework and rewrite everything. And this is it. It's still not perfect, but it's sort of readable code and way cleaner than before.
This version also fixes the problem I had with getting the current status of other software processes. Amazingly, it works now."
- Josia (09.10.2024)

What's Changed

The long-awaited release of version 1.4.0 - the big rework.

With this release, HTTP2MIDI is now a more stable and cleaner tool than ever before. The previous module.js is now split up and handles everything way simpler. All Action Handling and Triggering are now done in the functions.js in different classes depending on the software it controls. All direct Midi stuff has its file with midi.js. The index.js now handles the startup and calling the functions depending on the HTTP request you make.

The AHK scripts have been deleted since they had hardcoded mouse movements and the features weren't doable any other way. Also, the scripts were never used in the deployment since a fix of Presenter a couple of months ago.

v1.4.0 also now has working verification if StudioOne and Presenter are running. This is handled asynchronously in constant loops that check every second if the programs are running or not.

Another improvement in v1.4.0 is that the previous debug-helper is now history and the tool now uses swagger-ui. This change simplifies the testing for each individual action by a lot.

I also wrote a bit in the readme, that explains how you can customize and modify the tools to fit your needs. Check it out, if you need to do something like that

! Notice: changing the version in the config does not affect the functionality or actual version of the software

Updates

Rework the entire Tool by @ScheerleJo in #6

• Fix File Structure.
• update config
• Fix and rewrite the constant status for S1 and Presenter
• move Midi to a separate file
• move functions to a separate file
• call the different functions without the use of a switch case
• separate actions for Presenter and StudioOne
• rework the feedback for Companion
• update and fix documentation
• move Frontend from custom buggy HTML to Swagger-UI

Full Changelog: v1.3.2.2...v1.4.0

v1.3.2.2 Deactivated Midi Input

In this release the Midi Input is temporarily deactivated until the genericcly coded rework v1.4 is finished.

Full Changelog: v1.3.2.1...v1.3.2.2

v1.3.2.1 Bug Fixes

This Release fixes the Bug with the Studio One State. In the previous version, the status was always false independent of S1 being open or closed.
That is fixed with this version and correctly displayed while starting up.

Full Changelog: v1.3.2...v1.3.2.1

v1.3.2 Stability and Latency Improvements

Release Notes

With this release, HTTP2MIDI is now able to determine whether Studio One is open more efficiently. Now the application checks the status of Studio One when starting up and after every command is handled successfully. This lets one case open, whether something has changed since http2midi was opened and a function has been triggered. But this solution has the benefit that you do not have to wait on any package to find a process before executing a command. This saves up to half a second of latency.

Another improvement, mostly to get a clearer view of the functionality, all of the nested ifs in the handleAction function are now gone. This still could be improved but now it is clearer than ever before. ;)

! Notice: changing the version in the config has no effect on the functionality or actual version of the software

Updates

• Checking if S1 is running more efficiently while dealing with the action handler
• Fix spelling and expand the readme & documentation with command_list.md
• remove nested IFs in the handleAction() function
• Add version readout to startup and default config
• Update some functions to async for better performance

Full Changelog: v1.3.1...v1.3.2

v1.3.1 "The Feedback Update"

Release Notes

This release builds on a bug that I found in v1.3.0.
Because the Midi-input signal with the active recording status is delayed due to conversion and processing with midi, the recording status sent as a response to the HTTP-GET request has the wrong status.
With a new update in Companion, it is possible to create trigger loops that constantly get the current recording status without triggering a direct action in Studio One. Therefore a new handler branch /get is implemented.

Another improvement is the version readout in the console when starting the application. The current version can also be seen in the default config.
! Notice: changing the version in the config has no effect on the functionality or actual version of the software

HTTP2MIDI is now able to determine whether Studio One is open. When it is closed none of the MIDI-Commands for S1 get sent. This prevents some buggy stuff when first creating a marker and then opening S1 to record.

Updates

• Checking if S1 is running before sending MIDI-Commands
• Get continual feedback in Companion with the new handler branch
• Add MIDI-Input on debug-helper
• Add version readout to startup and default config
• Update some functions to async for better performance

Full Changelog: v1.3.0...v1.3.1

v1.3.0 MIDI Feedback

Release Notes

This release builds on a bug that occurred during the last Sunday service.
The server now asks for the status of the current audio recording in Studio One and receives this information via MIDI. That is accomplished by creating a new instrument device in Studio-One to access this feedback.

The MIDI input http2midi listens on can be changed in the default config as the MIDI output has been.
For the feedback to function, the MIDI input in the config must be active and correctly spelled.

Updates

• Update module.js for Midi-Callbacks
• Bug-Fixes

Full Changelog: v1.2.0...v1.3.0

v1.2.0 Implement AHK-Callback

Important!

This is a not utterly functional release. A fix for the presenter2midi_startup script is coming soon.

Release Notes

This release implements the feature for Callbacks from AutoHotkey to Node.js.
This is realized by using curl and the new Request-Handler /send/callback.

Another improvement is the implementation of ESLint in the Repo.

Updates

• Update index.js and module.js for Callbacks
• Implement Curl command in AHK-Scripts
• Bug-Fixes

Full Changelog: v1.1.0...v1.2.0

v1.1.0 AHK-Implementation

Release Notes

This release implements the AutoHotkey scripts in the workflow.
You can finally bind the midi-input of 'Presenter' with AHK. Also, the AutoExport-Feature is now working.

Updates

• Update midi2s1_export.ahk
• Set Coordinates for AHK-scripts
• Bug-Fixes

Full Changelog: v1.0.1...v1.1.0

v1.0.1 Minor Fixes

Some minor Fixes, with content and linking to websites from the debug-helper