Hi Normann, Thank you very much for providing this wonderful library. This was really helpful for me. Using a MidiOutDevice with Windows 64 bit I needed to change the casting of the callback function address from Cardinal to NativeUInt in Winapi.Midi.Devices.pas: function TPlatformMIDIDevice.OpenMIDIOutDevice: NativeUInt; var LResult: NativeUInt; begin LResult := midiOutOpen(@Result, DeviceID, NativeUInt(@mmeapiCallBack), NativeUInt(Self), CALLBACK_FUNCTION); . Cheers, Gunter
add SaveMidiFile method
Hello, good morning Norman, I would like to know if there is a way to list all the marks and the midi and 2nd file and if there is a way to get the data type byte1, byte2 etc. The interaction is send to midi out modified. With that it would be perfect to use in a midi program that I have already developed.
Olá bom dia Norman gostaria de saber se tem como listar todos os mark e do arquivo midi e 2° e se tem como pegar os dados tipo byte1, byte2 etc. A interação é mandar para o midi out modificadas. Com isso ficaria perfeito pra usar num programa midi que ja desenvolvi.
Olá bom dia Norman gostaria de saber se tem como listar todos os mark e do arquivo midi e 2° e se tem como pegar os dados tipo byte1, byte2 etc. A interação é mandar para o midi out modificadas. Com isso ficaria perfeito pra usar nom programa midi que ja desenvolvi.
Olá bom dia Norman gostaria de saber se tem como listar todos os mark do arquivo midi e 2° e se tem como pegar os dados tipo byte1, byte2 etc. A interação é mandar para o midi out modificadas.
Olá bom dia Norman gostaria de saber se tem como listar todos os mark do arquivo midi e 2° e se tem como pegar os dados em decimal. assim poderei alterar os acordes em tempo real.
Hi Norman, I have a new question about your beautiful components... I need to eliminate some events (text/lyrics/chords events) from midi file and replace them with other events (lyrics or text events). The question is: how can I delete events and insert new ones, and after that, save the midifile? Is it possible? Thanks for your advices Giuseppe
MIDI.Messages.FMXDemo works fine with Windows but doesn't with Android
Hi Normann! I connected a USB midi cable to my keyboard I compiled MIDI.Messages.FMXDemo as an Windows exe: I can read the midi messages on my PC application! Great :-) I compiled MIDI.Messages.FMXDemo as an Android apk: the app is running, I can see the comports, I can select my MIDI interface, but no message... Do you have any hint? What could I try to solve the problem? Thanks!! Mat
Hi Normann! Great piece of work!Thanks for sharing this! FYI, I managed to compile all the FMX demos except one: MIDI.Devices which uses Vcl.ActnList ! yours, Mat Win 10 22H2 Delphi CE 10.4 AndroidSDK-2525-21.0.40680.4203 AndroidNDK-21-21.0.40680.4203 AdoptOpen jdk-8.0.242.08-hotspot
Hi Normann! Great piece of work!Thanks for sharing this! I managed to compile all the FMX demos except one: MIDI.Devices which uses Vcl.ActnList. yours, Mat Win 10 22H2 Delphi CE 10.4 AndroidSDK-2525-21.0.40680.4203 AndroidNDK-21-21.0.40680.4203 AdoptOpen jdk-8.0.242.08-hotspot
Hi! Great piece of work!Thanks for sharing this! I managed to compile all the FMX demos except one: MIDI.Devices which uses Vcl.ActnList. yours, Mat Win 10 22H2 Delphi CE 10.4 AndroidSDK-2525-21.0.40680.4203 AndroidNDK-21-21.0.40680.4203 AdoptOpen jdk-8.0.242.08-hotspot
Hi! Great piece of work!Thanks for sharing this I managed to compile all the FMS demos except MIDI.Devices which uses Vcl.ActnList. - Win 10 22H2 - Delphi CE 10.4 - AndroidSDK-2525-21.0.40680.4203 - AndroidNDK-21-21.0.40680.4203 AdoptOpen jdk-8.0.242.08-hotspot yours, Mat
A minor fix, new project icon, and one demo project refactored towards MVVN pattern (test).
First demo project separated into view and model. Components adjusted.
I think this is good for me... thank you Normann :-)
Hi Giuseppe, This should be the easiest part. You only need a TMIDIOutDevices component, which will maintain a list of all your MIDI-output devices on your computer. This does not depend on a MIDI clock. From the TMIDIOutDevices component you can extract any of the available MIDI-output devices like: var LDevice: TMIDIOutDevice; LDevice := TMIDIOutDevice(MIDIOutDevices1.Devices[0]); (Above would properbly give you the built-in "Microsoft GS Wavetable Synth") Check if the device is opened: if not...
Hi Giuseppe, This should be the easiest part. You only need a TMIDIOutDevices component, which will maintain a list of all your MIDI-output devices on your computer. This does not depend on a MIDI clock. From the TMIDIOutDevices component you can extract any of the available MIDI-output devices like: var LDevice: TMIDIOutDevice; LDevice := TMIDIOutDevice(MIDIOutDevices1.Devices[0]); (Above would properbly give you the built-in "Microsoft GS Wavetable Synth") Check if the device is opened: if not...
Thank you Normann for your project... I have deepened my knowledge of BASS lib and now I believe I am able to extract the MIDI events stream. Now my question is: what is the correct way to send individual events to the midiout? I don't think I need the midi clock because the timing is already given by the bass library. I just need to know which of your components to use to open the midiout and send events ... Can you help me? Thank you :-)
Hi Giuseppe, I don't know much about Bass Library, so the two aren't built to be integrated. I'm sorry I wasn't able to help. Best regards, Normann
Hi Normann, I found your components a few weeks ago. I would like to integrate them in my application to play a midi file to an output device. Mi app is based on Bass Library and i can only extract a midi event stream. Is there a way to integrate your components to a bass lib based application to do that?
Applying style for forms and few clean-ups.
ComponentPlatformsAttribute fixed in all occurrences - no support for pidAllPlatforms before Delphi 10.3.2. And Lazarus files updated as well.
Copyright notices changed to norm4nn.dk, and zip-file uploaded with new build revision with a minor fix. No major changes to the codes.
Files prepared in accordance with the new Object Style Style Guide. Code Formatter has been invoked with default settings, and few flaws has been corrected manually.
A bug fixed in method of TMethodList.IndexOf. The old approach did not produce a valid result.
my machine has Delphi 11 with the latest patches installed, with all the Android pieces that come installed with Delphi. Attached the catalog repository. Is something wrong with what Delphi is installing? Do I need other SDKs for your components to work with Android? Best regasrds, Victor
my machine has Delphi 11 with the latest patches installed, with all the Android pieces that come installed with Delphi. Attached the catalog repository. Is something wrong with what Delphi is installing? Do I need other SDKs? Best regasrds, Victor
my machine has Delphi 11 with the latest patches installed, with all the Android pieces that come installed with Delphi. Attached the catalog repository.
Hi Norman, thanks for the response - didn't get any email from the board ... Anyway, attached the error message that Delphi 11 displays when trying to deploy to my Galaxy Tab A7. Eventually I renamed the demo project from "MIDI.Devices.FMXDemo.dproj" to "aMIDIDevicesFMXDemo.dproj" removing the dots - the project deploys and runs fine mow on the Tab A7. It shows the connected midi interface / midi output, but it can't be selected nor activated / opened - so the "Test" button doesn't gets enabled and...
Hi Norman, thanks for the response - didn't get any email from the board ... Anyway, attached the error message that Delphi 11 displays when trying to deploy to my Galaxy Tab A7. Eventually I renamed the name of the demo project from "MIDI.Devices.FMXDemo.dproj" to "aMIDIDevicesFMXDemo.dproj" removing the dots - the project deploys and runs fine mow on th Tab A7. It shows the connected midi interface / midi output, but it can't be selected nor activated / opened. Is there still a problem with these...
Hej Victor, Sorry no one had an answer to what "incremental installation not allowed" meant. I have no clue as to what could cause this. One thing I do know is setting up the right versions of Android SDK, NDK, and Java can be tough - from my experience. I upgraded from Delphi 10.3 to 10.4 recently, and it gave me a couple of problems. I had to go back to my 10.3 installation and find the exact same setup and versions of SDK and NDK I had that worked for my tablet. On my Delphi 10.4 and for my Lenovo...
sorry, forget to mention - i'm using Delphi 11 pro
Hi, I'm trying to run the "MIDI.Messages.FMXDemo" on my Galaxy Tab A7, but I get the error message that "incremental installation not allowed" and then when performing the streamed install that "..xxxxxxx... base.apk is missing" Can somebody advise? Thanks, Victor
Files prepared for new .zip-package.
Disabled local streaming of messages in the device classes because of a flaw noticeable with Windows Synth.
Added few stream classes, and fixed a problem with time-division and sequencing.
Updated project files for version 1.5 release.
Old 2nd generation SMF files removed, and new 3rd generation SMF streams added. SMF Save feature done.
Reworked the Clock and Event into a unified record helper. A target of using less type definitions in Native.Midi.Types.pas.
The iOSapi.CoreMIDI_.pas file is the minimal required implementation of the Macapi.CoreMIDI.pas for iOS. This file should be reworked and replaced, or simply use the Macapi.CoreMIDI if there are no difference in the two frameworks for CoreMIDI.
Components compiles into iOS Device 64-bit target with no issues, and stops only at deploying software onto the iPhone - given me "No provisioning profile found...". I'm not enrolled into any of the Apple Developer Programs, and paying 130 USD on yearly basis is a bit too much for any free open-source project. I'm satisfied having the components compile into MacOS and iOS Simulator, and having the iOS platform in "Beta", until anyone picks it up, confirms, or rework the components, so they actually...
So far components are running with no problems on Mac OS X, using Delphi and the Platform Assistant Server. Components are developed on Delphi 10.3.3 Community Edition targeting MacOSX 10.13 SDK. The aim is to have every MIDI component run with the same source and feature on Windows and on Mac OS X, and also include iOS and Android on this. /Normann
Home
Version 1.4.155 (2021-05-16) released With updated lock-free message queue, to prevent locks between threads on sudden high CPU loads. Work on (presumably) more stable timing thread using Real-Time Work Queue API is in progress. The Winapi.SysCtrls.Timers.pas has the option of using RTWorkQ, MMSystem, or the "built-in" threading timing solution used for the other platforms. The MMSystem is default, but the work on RTWorkQ will continue, and hopefully the interval in between timing can be shorten...
Lock-free message queue added, and work on RTWorkQ in progress.
After implementing a simple but effective lock-free queue for components, I went on measuring then time analysis and discovered another issue. To my surprise there is a big gap in performance in between different MIDI interfaces, presumably in the implementation of the drivers. The time difference in sending MIDI messages through my ESI Mate and a semi-pro Yamaha PSR keyboard is huge. On sudden CPU load ESI could take up until 50 ms (!) transmitting messages, compared to same measurements for others...
After implementing a simple but effective lock-free queue for components, I went on measuring then time analysis and discovered another issue. To my surprise there is a big gap in performance in between different MIDI interfaces, presumably in the implementation of the drivers. The time difference in sending MIDI messages through my ESI Mate and a semi-pro Yamaha PSR keyboard is huge. On sudden CPU load ESI could take up until 50 ms (!) transmitting messages, compared to same measurements for others...
After implementing a simple but effective lock-free queue for components, I went on measuring then time analysis and discovered another issue. To my surprise there is a big gap in performance in between different MIDI interfaces, presumably in the implementation of the drivers. The time difference in sending MIDI messages through my ESI Mate and a semi-pro Yamaha PSR keyboard is huge. On sudden CPU load ESI could take up until 50 ms (!) transmitting messages, compared to same measurements for others...
After implementing a simple but effective lock-free queue for components, I went on measuring then time analysis and discovered another issue. To my surprise there is a big gap in performance in between different MIDI interfaces. The time difference in sending MIDI messages through my ESI Mate and a semi-pro Yamaha PSR keyboard is huge. On sudden CPU load ESI could take up until 50 ms (!) transmitting messages, compared to same measurements for others topping at 0,25 ms using MMSystem threads. I...
After implementing a simple but effective lock-free queue for components, I went on measuring then time analysis and discovered another issue. To my surprise there is a big gap in performance in between different MIDI interfaces. The time difference in sending MIDI messages through my ESI Mate and a semi-pro Yamaha PSR keyboard is huge. On sudden CPU load ESI could take up until 50 ms (!) transmitting messages, compared to same measurements for others topping at 0,25 ms using MMSystem threads. I...
After some research and time analysis it turns out priority is not the problem. Both PostMessage and TThread.Queue are having blocking issues, up until 40 milliseconds on a single clock event for short and high CPU loads, and probably a lot more for the sequencing engine. I don't know if this a change in the architecture of CPU's, Windows or Delphi, but this was not an issue with MMSystem, 32 bit and early versions of Delphi. However, the messaging queue will be changed with a simplified lock-free...
Back in the old days (32bit) it was sufficient using Windows Multimedia API (MMSystem). It ran fast and stable, and did not get easily disturbed by performance load on a PC. Since moving to 64bit the MMSystem is no longer stable when load is heavy on the CPU. I created a thread applying tpTimeCritical priority, but even that is challenged by heavy loads. That is not satisfactory when clocks are critical. The next couple of weeks I will work on removing above issue by using the Real-Time Work Queue...
Back in the old days (32bit) it was sufficient using Windows Multimedia API (MMSystem). It ran fast and stable, and did not get easily disturbed by performance load on a PC. Since moving to 64bit the MMSystem is no longer stable when load is heavy on the CPU. I created a thread applying tpTimeCritical priority, but even that is challenged on heavy loads. That is not satisfactory when clocks are critical. The next couple of weeks I will work on removing above issue by using the Real-Time Work Queue...
Back in the old days (32bit) it was sufficient using Windows Multimedia API (MMSystem). It ran fast and stable, and did not get easily disturbed by performance load on a PC. Since moving to 64bit the MMSystem is no longer stable when load is heavy on the CPU. I created a thread applying tpTimeCritical priority to the thread, and even that is challenged on heavy loads. That is not satisfactory when clocks are critical. The next couple of weeks I will work on removing above issue by using the Real-Time...
Back in the old days (32bit) it was sufficient using Windows Multimedia API (MMSystem), it ran fast and stable, and did not get easily disturbed by performance load on a PC. Since moving to 64bit the MMSystem is no longer stable when load is heavy on the CPU. I created a thread applying tpTimeCritical priority to the thread, and even that is challenged on heavy loads. That is not satisfactory when clocks are critical. The next couple of weeks I will work on removing above issue by using the Real-Time...
So far, Lazarus only cover these MIDI components on Windows platform, because frameworks on different platform do not come with Lazarus, like Macapi.CoreMidi for Mac OS X. Hopefully these components would mature into these platform with this tool in future. For now units are parsed separately for Lazarus every time commit is executed. This ensures Delphi units nor Lazarus units are blurred with compiler directives. /Normann
So far MIDI components are running on the Android platform, with the exception no input handler is connected to any MIDI input device. The problem is noted in the Androidapi.Midi.Devices.pas file (line 185), where an JMidiReceiver instance is having issues connecting to JMidiOutputPort. MIDI output devices are working as expected. Android somehow managed to break every sense in calling MIDI output devices for input ports, and MIDI input devices for output ports. They say we have to see it from the...
So far these components is running with no problems on Mac OS X, using Delphi and the Platform Assistant Server. Components are developed on Delphi 10.3.3 Community Edition targeting MacOSX 10.13 SDK. The aim is to have every MIDI component run with the same source and feature on Windows and on Mac OS X, and also include iOS and Android on this. /Normann
So far, Lazarus only cover these MIDI components on Windows platform, because frameworks on different platform do not come with Lazarus, like Macapi.CoreMidi for Mac OS X. Hopefully these components would mature into these platform with this tool in future. /Normann
Updated version info for the readme.txt file.
Prepared files for auto build processing.
Changed license note, and prepared units for Lazarus support.
The main reason for the Android support being in Beta is creating instance of JMidiReceiver and connecting it through JMidiOutputPort(Result).connect(JMidiReceiver) turned out to be missing a step. Hopefully I can find a solution for this, or someone has an idea what is missing. The output device (which is input in the real world) is running, and the MIDI clock seems to be running stable for the purpose. /Normann
Found a problem with the first Native13 zip file and package compiling.
The main reason for the Android support being in Beta is creating instance of JMidiReceiver and connecting it through JMidiOutputPort(Result).connect(JMidiReceiver) turned out to be messing a step. Hopefully I can find a solution for this, or someone has an idea what is messing. The output device (which is input in the real world) is running, and the MIDI clock seems to be running stable for the purpose. /Normann
The main reason for the Android support being in Beta is creating instance of JMidiReceiver and connecting it through JMidiOutputPort(Result).connect(JMidiReceiver) turned out to be messing a step. Hopefully I can find a solution for this, or someone has an idea what is messing. The input device (which is output in the real world) is running, and the MIDI clock seems to be running stable for the purpose. /Normann
The main for the Android support being in Beta is creating instance of JMidiReceiver and connecting it through JMidiOutputPort(Result).connect(JMidiReceiver) turned out to be messing a step. Hopefully I can find a solution for this, or someone has an idea what is messing. The input device (which is output in the real world) is running, and the MIDI click seems to be running stable for the purpose. /Normann
Initial application of changing clock position applied.
Hi Gert, Thanks! I will take your second question into the next version, and make it possible to set positions, and of course setting position by clock. And thus support jumping backward or forward ;-) Best regards, Normann
Hi Gert, Thanks! I will take your second question into the next version, and make it possible to set positions, and of course setting position by click. And thus support jumping backward or forward ;-) Best regards, Normann
I think I'v got the volume covered. Always to fast to ask: TMIDIOutDevice(FMIDIOutDevices.SelectedDevice).SendMIDIControlChange(0, Ord(ccChannelVolumeMSB), 127);
Hello, This seems to be a great libraray! I've got 2 questions: Is it possible to set the master playback volume of a midi out device? Is it possible to set the starting position in a midifile for playback? Thanks!
AddSequence sorting according to Clocks, and inserted events at proper position. Fixed a potential buffer leak when text events are zeroed out in length.
Prepared for next release, version 1.3.133.
Home
Home
Home