Activity for Normann Simplified
-
Normann Simplified committed [42287a]
A bug fixed in method of TMethodList.IndexOf. The old approach did not produce a valid result.
-
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...
-
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
-
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
-
Home
-
Home
-
Home
-
TMIDIThruDevice split into platform classes to support different types of buffers for platforms.
-
Stabilized the Android MIDI sequencer, and setting up new MIDI Clock thread policy and priority for Android and MacOS/iOS.
-
Proper ornaments for platform support for each component. And package project files prepared for C++ Builder. Timers and threaded timing has been refactored to support different approaches in platforms, e.g. handling of priorities and process class.
-
Tested code for next package release, and made minor fixes.
-
Prepared components for Android platform - still in Beta.
-
readme.txt file updated to new version.
-
Packages prepared for 1.2.119 release.
-
Added a constant for default high priority when in designer mode.
-
Minor fixes, and now OSX 64 ready.
-
Cleaned up code, refactored, renamed and relocated files, and prepared components for Mac OSX 64bit. Created FMX projects to demonstrated all Win32, Win64, and OSX64.
-
First running version of SMFSequencer for Mac OSX (64bit) and FMX demo projects committed. Debugging in progress.
-
Removed unused files.
-
Renaming and cleaning, android files added, and package files relocated.
-
I was a little surprised the iOSapi.CoreMIDI was not included in the framework for iOS, like it is in the framework for Mac OSX. I have created a temporary iOSapi.CoreMIDI_.pas file with the minimum definitions of identifiers used as in Macapi.CoreMIDI.pas. It compiles for the iOS simulator, but I have no idea if it runs as I don't have sufficient equipment to test the platform fully. Thus, this platform will be in beta for upcoming releases, and will need special attention later. The components...
-
Files for iOS and Android prepared. Files renamed for Winapi, Armapi, and Macapi.
-
Components prepared for Native20210330.zip (1.1.105 release), tested, and few minor changes added.
-
Major rework to prepare units for Mac OSX support. Added and deleted files, and added FMX demos - built on macOS High Sierra (10.13.6) and XCopy 9.2 with SDK 10.13.
-
Version 1.1.x released The second package is released (Native20210330.zip), and includes packaging of: MIDI Components: TMIDIInDevices, TMIDIOutDevices, TMIDIClock, TSMFFile, TSMFSequencer, TMIDIThru (beta). System Components: TSysTimer. Device Components: TDeviceListBox, TDeviceComboBox. Target for version 1.2.x is: TMIDIRemotes, TRemoteDevices, TGaugeMeter, TSpectrumMeter, and alike, but not yet decided.
-
Version 1.1.x released The second package is released (Native20210330.zip), and includes packaging of: MIDI Components: TMIDIInDevices, TMIDIOutDevices, TMIDIClock, TMIDISMFFile, TMIDISimpleSequencer, TMIDIThru (beta). System Components: TSysTimer. Device Components: TDeviceListBox, TDeviceComboBox. Target for version 1.2.x is: TMIDIRemotes, TRemoteDevices, TGaugeMeter, TSpectrumMeter, and alike, but not yet decided.
-
Fixed a potential blocking issue when waiting for outgoing MIDI headers, and changed thread busy flag to a less resource intensive approach.
-
Fixed the MIDI header issues, and added the missing Native.Type unit.
-
Prepared for sequencing component for final testing, and fixed issue with Delta Timing when sequencing SMF files.
-
Fixed threaded timers with locking mechanism before releasing resources. Work on sequences in progress.
-
Prepared files for SMFFile and SMFSequencer components.
-
Updated readme.txt file.
-
The 64-bit I/O with long messages is now running with proper headers as well.
-
Working on running SysEx on Win64.
-
Finished support for System Exclusive, and options for Note On = 0 to Note Off.
-
Version 1.0.x released The first package is released (Native20210314.zip), and includes packaging of: MIDI Components: TMIDIInDevices, TMIDIOutDevices, TMIDIClock, TMIDIThru (beta), and TSysTimer. TDeviceListBox, TDeviceComboBox. Target for version 1.1.x is: TMIDISMFFile, TMIDISimpleSequencer, TSpectrumMeter, and supporting components and classes. Target for version 1.2.x is: TMIDIRemotes, TRemoteDevices, TGaugeMeter, and alike, but not yet decided.
-
Added TDeviceComboBox, and prepared files and project for final 1.0.x release.
-
Added System Exclusive features. Prepared packages for version 1.0.x release, and updated the readme.txt file.
-
Support system messages, and included a demo for real time messages. Prepared the library for System Exclusive messages.
-
Hi guys, Thanks for waiting. I've updated the files, and added 4 sample projects. Beta release notes: The update has the GNU General Public License notice, and the basic components with basic features are ready for Win32 and Win64 platforms. I will work on the support for System Exclusive messages in the next couple of weekends. After that, the plan is to add support for more platforms before going for other supporting components or the visual components. If you find any issues, just let me know...
-
Hi guys, Thanks for waiting. I've updated the files, and added 4 sample projects. Beta release notes: The update has the GNU General Public License notice, and the basic components with basic features are ready for Win32 and Win64 platforms. I will work on the support for System Exclusive messages in the next couple of weekends. After that, the plan is to add support for more platform before going for other supporting components, or visual components. If you find any issue, just let me know ;-) Best...
-
Hej guys, Thanks for waiting. I've updated the files, and added 4 sample projects. Beta release notes: The update has the GNU General Public License notice, and the basic components with basic features are ready for Win32 and Win64 platforms. I will work on the support for System Exclusive messages in the next couple of weekends. After that, the plan is to add support for more platform before going for other supporting components, or visual components. If you find any issue, just let me know ;-)...
-
Moved private methods to public section of Win32 platform specific devices.
-
Finished initial beta versions of MIDI components, and included 4 sample projects.
-
Hi Nik, Sorry for the late response - my mail did not notify me on filtered mails :-/ But yes, I can work on a couple of simple examples, and upload these into a separate folder the coming week. Also I hope I can make some updates on the components as well. Best regards, Normann
-
First package release is set to January 1st 2021. It will support basic MIDI componnets on both Win32 and Win64, and lay down foundation for the other platform, and work on sequencing engine and file stream componts as well.
-
Home
-
Win32 and Win64 handles and callbacks realigned.
-
Test commit
-
First commit
-
Second commit
-
Home
-
Home
-
Home
-
Home
-
Home
1 >
