OutputDevice on iOS

[ayaphi]

Hi there,

and first of all : a huge thanks Maxim for your amazing work respectively library ... its a joy to discover & use it and your documentation is great (and really needed in that detail, because the feature richness has a complexity that can hardly be discovered by try and error ... thanks !!!).

I played around with the library in a Windows App SDK project and it works great and now I am thinking, if its somehow possible to use it in a .NET MAUI project running on iOS.

Its clear that on iOS the Device API is not implemented, which leads to the frist question : Maxim has put so much effort in building and evolving this library, so there might be a good reason that there is no Device API implementation for iOS, e.g. because of technical restrictions or issues - as Xamarain.iOS is a long time around and .NET MAUI moving in its footsteps.

What's obvious : a high resolution time is needed that could "drive" the iOS implementation of IOutputDevice, which could be done quite nicely in .NET Maui project with partial classes and methods (see : https://learn.microsoft.com/en-us/dotnet/maui/platform-integration/invoke-platform-code?view=net-maui-7.0#partial-classes-and-methods).

But as I have no experience in using iOS Plattform APIs or classes in .NET (neither via Xamarin.iOS nor via .NET Maui), I am not aware of the limitations that exist - I guess that some API & classes, even if they are present in .NET MAUI through bindings the team has implemented, they might cause somehow trouble using them via C#, because of the technical nature of how .NET MAUI is running on iOS - it's a different game than on Windows and maybe even on MacOS.

As Timer can have high demand on a device resources (e.g. draining battery if they keep runing on the CPU like on a rat race for getting that high resolution ;-), I could imagine, that even if there is a high resolution timer (with 1ms support) on iOS available, it cannot be used "that easy" in a .NET MAUI app.

If that's the case, what about a "sidechain" workaround : is there a chance to link a piece of swift code to the .NET MAUI project that implements an output device (with a maybe slightly different api)?

Has anyone experiences in this "deep fields of iOS" ;-) and maybe some useful tipps ?

Thanks in advance ... cheers and happy new year.
ayaphi

[melanchall]

Hi,

First of all, thanks for such kind words!

As for iOS support – there is a chance that the library will work on the platform due to macOS support. As far as I know, both iOS and macOS use the same system APIs. If you can test a simple app on iOS, it would be great.

By the way, high precision timer is needed for Playback, not IOutputDevice.

[ayaphi]

Hi & thanks for the quick reply,

I did a first quick test, which failed : running on a Windows 10 machine in Visual Studio 17.4.3 and a "paired Mac" (which does the build and runs the iOS simulator, which is then remote viewed on Windows), I used my current .NET MAUI "evaluation" project (using .NET 7).

I just added the DryWetMidi 6.1.3 Nuget Package and did a build, which failed with the message :

clang++ exited with code 1:
ld: library not found for -lMelanchall_DryWetMidi_Native64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Not sure if runing Visual Studio on Windows may cause the trouble that the "native library" is not present, but chances are ;-).

I will do another test on the Mac, which is a Apple Silicon M1 based Mac Mini by the way - I quickly browsed through the Issue 204 in which you solved the Apple Silicon issue, so I guess this issue might be related to "running on windows".

Nevertheless it might be a hint for a new "easter egg" in the strange but also beautiful garden of cross plattform development ;-) ... and hence be useful to see if there is another surpirse that comes along with .NET MAUI.

I will be back with infos, when I did the test on the Mac.

cheers & have a nice one
ayaphi

[ayaphi]

Hi,

I tested it with a simple .Net MAUI project (default tempate for .NET Maui in Visual Studio) on the Mac (Apple Silicon based) and got the same error in Visual Studio for Mac (Version 17.4.2) as mentioned in my answer above : for an iOS build and also for Mac Catalyst.

I also did a quick cross check with a .Net Core Console project on the Mac, which produces no errors, although I did not call any APIs of DryWetMidi (just Nuget Install & build).

Interesstingly the same DryWetMid DLL's can be found in the build output directory of the .Net Core Console projects and the .Net MAUI build for iOS and Mac Catalyst.

Any ideas ?

cheers
ayaphi

[melanchall]

Hi Ayaphi,

Thanks a lot for your tests! Well, let's do following things:

1. Please create fresh .NET MAUI project.
2. Add the universal.dylib file from this archive – universal.zip – to the project and set Copy to Output Directory to Copy always for the file.
3. Add this lines in some class in the project:

   [DllImport("universal.dylib", ExactSpelling = true, CallingConvention = CallingConvention.Cdecl)]
   private static extern int Foo();

4. Call Foo(); somewhere in this class.

Now please try to do all the actions you did before (build and send to iOS device). Does the build succeeds? If yes, please remove .dylib suffix from DllImport and try again.

universal.dylib contains a simple function in C:

int Foo() { return 234; }

Thanks,
Max

[ayaphi]

Hi Melanchal,

before I followed your instructions entirely, I did a step in between – starting off from the default (fresh) project template for .NET MAUI.

I just created a folder “Libraries” in the project, pasted “universal.dylib” in there and set its property “Copy to Output Directory” to “Copy always” and did a build. This resulted in the same error :

Error : clang++ exited with code 1:
ld: library not found for -luniversal
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This is strage - maybe there are some default build actions triggered purely by the file extension ".dylib"? But I cannot see anything like that in the c# project file. Maybe they are configured in the Xcode build tools pipeline?

As removing the ".dylib" file extsion, the build succeed - as its just an ordinary content file.

---

Following your instructions entirely, using conditional compilation (#if IOS … #endif), it resulted in the same error like above.

After that I tried it with the “dylib” file extension removed from the DllImport statement – with the same result.

---

Just to verify that the pure existence of the library is not somehow a problem, I did a windows build and this worked out.

If you got other ideas that I can test, please let me know.

Cheers
ayaphi

[ayaphi]

Hi,

just a quick note regarding the scenario when there is just the file "universal" (extension ".dyliob" removed) and no other code added.

I overlooked a build warning that might give a hint :

The file '...TestifyMidi\Libraries\universal' does not specify a 'PublishFolderType' metadata, and a default value could not be calculated. The file will not be copied to the app bundle.

I modified the output and shorted the path, that's why there is a "..." and not the full path.

cheers
ayaphi

[melanchall]

Hi Ayaphi,

Thanks again! Well, it looks like it would be better to report an issue to https://github.com/dotnet/maui/issues. Can you please create one with all the info you've provided here about fresh MAUI project and universal.dylib? Please provide a link to the issue here so I can track the progress too. Thank you for your assistance.

Max

[ayaphi]

Hi Melanchall,

yes I can open an issue over at .NET MAUI, but could you please give me some technical insights beforehand, so that I can hand over all the relevant information?

As Univeral.dylib is a dynamic link library from "Planet Apple" ;-), did you build it with Xcode? But for which targets? Is it, as the name suggests, a "universal build", which might be a really CPU architecture agnostic byte format for all modern apple devices?

I remember the term universal in Apple land only as a consumer, where it meant that the app can run on an iPhone and iPad (and nowerdays maybe on a Mac via Mac Catalyst). So what about x86 and x64 - can universal.dylib also be used in apps on Intel based Macs (e.g. in a .NET Core Console app)?

Are there specifics in the Xcode makefile that build the universal.dylib, which the "bug hunter" over at .NET Maui should know?

As the source code is a 1-liner, is there also a default makefile template in Xcode that the bug hunters my use, in the case they do not want to use other peoples binary codes (virus and alike) and rebuild the minimal library for themselves - also to be sure that no unknown (they are not aware of) flag in the makefile causes whatsoever sideeffect?

cheers and have a nice one
Ayaphi

[melanchall]

Hi Ayaphi,

universal.dylib has been built using command line tools clang and lipo:

clang -shared -undefined dynamic_lookup -o arm64.dylib arm64.c -arch arm64
clang -shared -undefined dynamic_lookup -o x86_64.dylib x86_64.c -arch x86_64
lipo x86_64.dylib arm64.dylib -output universal.dylib -create

from this simple files (this is a PowerShell script that creates the files):

Set-Content -Path .\arm64.c -Value "int Foo() { return 234; }"
Set-Content -Path .\x86_64.c -Value "int Foo() { return 345; }"

So the Foo returns 234 for arm64 arch (Apple Silicon chips) and 345 for Intel CPUs. So the universal.dylib represents universal dynamic library which can be used on both old and new Apple CPUs.

So you can pass all this info into an issue in .NET MAUI. We've determined that your problem is related not with DryWetMIDI but with how DllImport's work at all on MAUI + iOS. If Microsoft provides instructions on how to fix the issue, I'll try to integrate the fix in the library.

Thanks,
Max

[ayaphi]

Hi Melanchal,

before I reach out to the .NET MAUI team, I did a quick google search on the topic and found 3 hints, but I could not dig into them deep enough by now.

The main thing seems to be : external libraries needs to be statically linked for iOS in .NET MAUI apps and we have to find a proper way to do this in .NET MAUI ".csproj" - not a place I know like the back of my hand by now ;-)

1.) Xamarin iOS related (most of the Xamarin stuff is still valid for .NET MAUI) : https://learn.microsoft.com/en-us/xamarin/ios/platform/native-interop#linking-your-library says "Any third-party library that you consume needs to be statically linked with your application."

So there has to be extra stuff for the project build. The webiste above states extra flags (-gcc_flags and a string parameter), which I do not know how to integrate in the ".csproj" makefile (alike) of the .NET MAUI project yet. Respectively how to let the ".csproj" generate that for the Xcode build ... these are the downsides (dark sides ?) of abstracted cross plattform magic ;-)

2.) Also there has to be some additional bootstrap code in c# : https://learn.microsoft.com/en-us/xamarin/ios/platform/native-interop#accessing-c-dylibs .

3.) A closed issue on github gives another hint to "@rpath/" prefix : dotnet/maui#4569 (comment)

These could be the missing pieces - does the above make any sense to you (taking a quick glance)?

cheers & happy new year
Ayaphi

[melanchall]

Hi Ayaphi,

Thank you! Hmm, it seems native library for iOS should have .a extension and be static, not dynamic .dylib.

I think we should take a break until I prepare prerelease NuGet package for you with .a file inside. And then we can proceed with our journey. Honestly I don't know right now, how such .a files are created, so please be patient.

Thanks again,
Max

[ayaphi]

Hi Max,

thanks for digging into it ... and I will be patient ;-)

I researched a little bit further and found out, that aside from building a static library, an "iOS Binding project" might be the solution for integrating the "wrapped iOS native library" into the .NET MAUI project.

Xamarin iOS & binding Objective C, incl. a makefile for creating a "fat library (*.a) : https://learn.microsoft.com/en-us/xamarin/ios/platform/binding-objective-c/walkthrough?tabs=macos#creating-a-fat-binary

Xamarin iOS & binding Swift : https://learn.microsoft.com/en-us/xamarin/ios/platform/binding-swift/walkthrough

And a newer Version for .NET MAUI and binding an iOS native library : https://github.com/kinfey/AMapMAUIControls/blob/main/tutorial/en/01.iOSBinding.md

In Visual Studio 17.4.3 on Windows there is a project template called "iOS Binding Library" (as the author of the last mentioned website used a command line approach), but I did not tried it yet.

Nevertheless the Objective Sharpie (https://learn.microsoft.com/en-us/xamarin/cross-platform/macios/binding/objective-sharpie/) tool will be needed to generate the basics for the iOS binding library project on the Mac.

Maybe I give this workflow a try with a simple Swift Library / Framework, as this might be a foundation for a "multi purpose" Swift bridge (sidechain ;-) that could be helpful for other MIDI & Audio "stuff" on iOS ... the world of music apps on iOS is really awesome, especially those AUv3 plugins and hosts (like AUM) and being able to interact with those would be a fascinating opportunity - and might also open up new satisfying usecases for DryWetMidi ;-).

cheers
Ayaphi

[melanchall]

Hi Ayaphi,

Well, I've created a fat .a file for arm64 and x86_64 archs (I've skipped 32-bit old archs): Melanchall_DryWetMidi_Native64.zip. Build succeded without errors but I can't check if the result file is valid or not:

Building arm64 .a...
ar: creating archive Melanchall_DryWetMidi_Native64_arm64.a
a - Melanchall_DryWetMidi_Native64_arm64.o
Building x86_64 .a...
ar: creating archive Melanchall_DryWetMidi_Native64_x86_64.a
a - Melanchall_DryWetMidi_Native64_x86_64.o
Merging .a files into a single unversal one...
Merged archs are:
Architectures in the fat file: Melanchall_DryWetMidi_Native64.a are: x86_64 arm64 

Can you please take the file from the provided archive, add it to your project (I suppose it would be useful to set “Copy to Output Directory” to “Copy always” for the file) and repeat all previous actions regarding build and sending to iOS device?

Also please note that I will be AFK until Jan 11, so I won't be able to do any coding before that day. So if the build will fail with the provided .a file, I'll get back to you on Jan 11.

Thanks for your assistance and happy new year!
Max

[ayaphi]

Hi Max,

I tested Melanchall_DryWetMidi_Native64.a with

[DllImport("Melanchall_DryWetMidi_Native64.a", ExactSpelling = true, CallingConvention = CallingConvention.Cdecl)]
private static extern int Foo();

and calling the function, assigning its return value to the Text Property of (XAML) Label.

I still get a build error, but we are getting better & closer to "get it going" ;-) ... the messages are now

clang++ exited with code 1:
ld: in .../TestifyMidi/Libraries/Melanchall_DryWetMidi_Native64.a(Melanchall_DryWetMidi_Native64_x86_64.o), building for iOS Simulator, but linking in object file built for macOS, file '.../TestifyMidi/TestifyMidi/Libraries/Melanchall_DryWetMidi_Native64.a'
clang: error: linker command failed with exit code 1 (use -v to see invocation) TestifyMidi

I cut out some of the path and replaced it with "..." and TestifyMidi is the name of the project.

Have a good time and I am glad to assist you later in January.

cheers
Ayaphi

[ayaphi]

Hi Max,

long story short : I found a working solution that works with Swift and I will change gears and develop the app in Swift & SwiftUI.
But I still would like to see (and assist you with try & maybe error ;-) DryWetMidi playback ready on iOS with .NET MAUI – if you are still interested.

+++

In a nutshell: the solution on “planet iOS” is AVAudioSequencer, which is essentially a MIDI sequencer & playback engine integrated into AVAudioEngine – it can load & playback MIDI files and also supports adding and removing MIDI events (note, tempo and more).

Inside AVAudioEngine one can use AVAudioUnitSampler to load SF2 Soundfont files (sample libraries) for playing the sound for the notes of the midi tracks.

Its also possible to let AVAudioSequencer route a track (chunk) of the loaded midi file to a certain AVAudioUnitSampler instance and hence a multi timbral song playback and editing is possible to achieve.

To a first degree this also works in .NET MAUI with the provided native bindings – loading a MIDI file into AVAudioSequencer, a SF2 into AVAudioUnitSampler, and playing back the MIDI file with that sounds works fine (I tested it with 2 tracks and 2 audio sampler). But when it comes to “track editing”, the bindings in .NET MAUI are not complete, so e.g. AVMusicTrack in .NET MAUI misses all methods, like addEvent.

I don’t know why these API are missing as the promotion of .NET MAUI has always been “you can access all native APIs on the supported platform”, but I will not ask (over on their Github project site) and not dig into it.

I think .NET MAUI could become a great technology, but if it’s the right choice, depends on what one wants to achieve and beside that, from my exploration of .NET MAUI coding so far, it feels like its still in the “get it going” phase – it has not settled yet.

.NET MAUI might become a good choice for line of business apps, social media apps and alike – but if one wants to deeply integrate with a essential framework of one of the supported platforms, like Audio & MIDI (both !) and the ecosystem of AUv3 plugins on iOS, I think its a better idea to use the native programming language and techniques & tools of the platform.

And by the way: using AUv3 plugins and integrating one’s own app (e.g. a fancy MIDI Sequencer ;-) in the AUv3 ecosystem, the Swift framework AVFAudio (that houses AVAudioSequencer and AVAudioEngine) most probably is not the best choice either and one has to drop into the objective-c layer or use a promising Swift library from the AudioKit project (https://github.com/AudioKit/AudioKit).

+++

So that’s for now – but as I said : if you got new DryWetMidi .NET MAUI ideas & builds for me to test on an iOS device, please let me know.

As using DryWetMidi for pure MIDI creation & playback on .NET MAUI might make sense, especially when we can get an easy access to midi ports that are published in the core midi runtime (I am not sure if this is the right term, still digging ;-) and hence connect and playback to AUv3 hosts and DAWs on iOS.

Cheers
Ayaphi

[ayaphi]

Hi Max,

I thought I did a mistake, but I did not – as sometimes the bug is not in code, but in front of the monitor ;-).

I copied the libraray fat.a in a folder called Libraries and did not mentioned the path in any way in the DllImport Attribute.
But it makes no difference - I moved fat.a in the root directory of the project, where also there is the file (MainPage.xaml.cs) in which I call Foo, and the same System.DllNotFoundException: fat.a occurs.

Also I checked that fat.a is deployed to the output folder : its there alongside with other libraries like for example icudt.dat, libicuuc.a (so static libraries are still somehow in use - but maybe with binding wrappers ?). The output folders are bin\Debug\net7.0-ios\iossimulator-x64 and bin\Debug\net7.0-ios\ios-arm64 by the way and reside also on the windows machine.

And also – that might be most interesting : the same error occurs when I remove fat.a from the project entirely. For that build & deploy I did a manual removal of the build directories (bin and obj) on the windows machine beforehand and also a "Clean Solution" in VS – although I do not know if these are only shadow directories and the ones on the build host matter and are used.

{System.DllNotFoundException: fat.a   
at ObjCRuntime.Runtime.ThrowException(IntPtr gchandle)   
at UIKit.UIApplication.UIApplicationMain(Int32 argc, String[] argv, IntPtr principalClassName, IntPtr delegateClassName)   
at UIKit.UIApplication.Main(String[] args, Type principalClass, Type delegateClass)   
at TestifyMidi.Program.Main(String[] args) in F:\Developments 4 use\MAUI\TestifyMidi\TestifyMidi\Platforms\iOS\Program.cs:line 13}

Hope this helps - if you got some news, new builds or tests to perform for me, please let me know.

cheers
Ayaphi

[melanchall]

Hi Ayaphi,

Thanks again! I have several quick questions:

1. Do you see fat.a on the target device (real or simulator) somewhere? If yes, can you please show me the path where the file is?
2. Do you mean you tried to put full path to fat.a on target device in DllImport? If yes, can you please show how you specified the path in the attribute?

Honestly, right now I don't understand how to proceed with the issue. Maybe it would be better to create a question on Stack Overflow. Can you please provide me entire test solution so I can attach it to the question?

[ayaphi]

Hi Max,
sorry for the confusion - I was too much in a hurry.

Next try ;-) ... and as I have found the place where the app bundles, that are deployed to the simulator, are saved on the mac in the meantime, things should get clearer.

The way I tried to include fat.a to the deployed package this morning did not work : it does not matter, if one puts fat.a in the root directory of the source files or in a subordinated (nested) self named folder like "Libraries" e.g. - in none of the cases the file is copied to the deployment / app package. It does not even matter what the "file properties" settings are, like Copy to Output Directory - this technique only works on Windows, but not in "cross plattform land" ;-).

I verified this by opening the app package (which is just a zip file) that was deployed to the iPhone simulator : fat.a was missing.

And by the way : there are also none of the other *.a library files in the package, of which there are 18 in the bin output folder on the windows machine with names like Microsoft.iOS.registrar.a, libxamarin-dotnet.a, libextension-dotnet.a, libSystem.Native.a and so on. I do not know what kind of intermediate state these file represent and why they are there and not in the deployed bundle.

This should not confuse us, but maybe a reminder worth to keep back in our heads : these static libraries have different "kind of living" in .NET MAUI land.

+++

The solution for getting fat.a into the deployed app package is to use the right project folder. It has to be in \Resources\Raw (which is created by the default project template by the way) as you can see in the screenshot and the correct Build Action is set to MauiAsset automatically :

Then it will be deployed in the root folder of the App package, which means in the same folder in which the .NET MAUI assembly of the project exists (whose name is Testify in this case) - the following is the content of the Testify.app (which is a Zip file) :

...

I hope this makes it clearer.

But I still get the System.DllNotFoundException: fat.a exception when I call Foo, although fat.a seems to be in the right place in the app package.

My Code is just the default project template of .NET MAUI with fat.a added and the code behind file of MainPages changed as shown above.

In order to upload the entire project as a zip file for reproduction by others like on stackoverflow, I have to take some more time and investigations, because I have setup automatic signing in Visual Studio with my paid apple developer account and I must be sure that no sensitive data or even signing bits would be included ... do not want to see an surprise / easter egg that claims to be set out in the wild by me ;-).

If you still think it would be helpful (altough the screenshots in this post "tell it all"), let me know.

have a nice weekend, cheers
Ayaphi

[melanchall]

Hi Ayaphi,

Many thanks for the huge amount of work done on solving the issue! Unfortunately I haven't any iOS device so can't to handle the problem without your help.

Well, we have fat.a in the bundle. But how an application runs on iOS? I suppose the bundle should be unzipped first to run the app. So let's do a superquick check. Can you please change this part

Foo().ToString();

to

Assembly.GetExecutingAssembly().Location;

for now. You'll see the directory where the current code executes from. Is fat.a there? If not, can you put it there manually and call Foo?

As for providing a zip with the solution – I suppose yes, I need it. I think I'll create an issue on MAUI repo. They want the link to the repo with a solution to reproduce the error. So if you can create a public repo with your solution, it would be even better than zip file. We can then continue discussion within the issue in MAUI project.

Thank you for all your help,
Max

[ayaphi]

Hi Max,

first of all I have to clarify my last comment : I mixed up a little bit my research on iOS app deployment and what I have found out in the folder hierarchy on the mac build host that runs the simulator – sorry, for the misleading information … I am very focused on another “intense” project and parts of my analytic & coding brain never leaves it : hence less resources for “side path projects / investigations” and maybe some dropouts in information processing on “low priority side path threads” 😉.

Concerning zip file - it’s the output of the final build, when one wants to deploy the iOS app e.g. to the app store : projectname.ipa (aka IPA Bundle, which is a zip file).

Concerning what is deployed to the simulator – it’s a folder (named by a UUID) in which there are 2 files : BundleMetadata.plist and projectname.app, where the .app extension is hidden on the Mac (Testify is the name of the project I use), as you can see in this screenshot taken from the finder on the Mac :

Basically projectname.app is a folder (which you cannot open & look inside it on the Mac by default - the content is hidden away, but not compressed) and the screenshots from my last comment were taken from that folder (copied from the Mac to the Windows machine).

By the way: the same folder projectname.app is present in the output directory of Visual Studio e.g. …\Testify\Testify\bin\Debug\net7.0-ios\iossimulator-x64\Testify.app.

But I did not verify if the content is identical - chances are, but BundleMetadata.plist e.g. is not present at all in the project on the Windows machine – it might be generated from info.plist, which is present in …\Testify\Testify\Platforms\iOS and other information one provides in the metadata properties of the project.

+++

I tested Assembly.GetExecutingAssembly().Location; and it pointed correctly to the app folder on the Mac build & simulator host and fat.a is there. So the platform invoke should work, if it is supported.

My guess (but I just scratched the surface by googling and quick reads of some parts that draw my attention) : platform invoke of static libraries (*.a libraries) are no more or not yet supported, and one has to use binding projects.

The basic coding workflow is described here for Xamaring iOS – although I do not know it is valid for .NET MAUI : https://learn.microsoft.com/en-us/xamarin/ios/platform/binding-objective-c/walkthrough?tabs=windows#walkthrough

+++

I only can provide you a Zip file with the test project, as I have not setup a Github toolchain yet and unfortunately I got not the time to do this right now – nevertheless I hope it helps : Testify.zip

Have a nice day & cheers
Ayaphi

[melanchall]

Hi Ayaphi,

Thanks for the info you've provided! At this moment I have no ideas what to do further. So I've created questions:

• on .NET MAUI repo – DllImport with .a file for iOS in MAUI dotnet/maui#12675
• on StackOverflow – https://stackoverflow.com/questions/75126187/dllimport-with-a-file-for-ios-in-maui

Our next step is to wait for a response :) If some info will be requested, I let you know.

Thanks again! Good luck with your main project and have a nice coding,
Max

[melanchall]

Hi @ayaphi,

Can you please check suggestions from this comment dotnet/maui#12675 (comment)? Maybe it would be better to answer right in that issue in MAUI repo.

Thanks,
Max

[ayaphi]

Hi Max,

I tested the suggested and it worked out - I retrieve "234" as expected, see my comment .

As I read your comment, that's sadly not the end of your efforts, as you have to figure out how to integrate this into your single cross-plattform codebase.

But I think & hope this will be less tricky with the help of the .NET MAUI teams, as this is their "core business / subjective" ;-).

Thank for all your efforts too and if you got somehting new to test out, please let me know ... its great to see your library coming along to iOS via .NET MAUI with the entire feature set!

cheers
Ayaphi

[melanchall]

Hi Ayaphi,

Great! Thanks you a lot! Yes, single cross-platform codebase and all those native-related things is a challenge :) But right now our next step is to check whether DryWetMIDI API works on iOS or not.

For that check I will take your solution, insert all sources of DryWetMIDI there and change library name in all DllImport's to __Internal. Also I'll build an .a file containing all required Apple API. And then I send the solution back to you, so you can check it with iOS devices.

Meanwhile can you please say are you able to attach some MIDI devices to the target iOS one or create virtual ones so we can test DryWetMIDI on something real? :)

Thank you in advance,
Max

[melanchall]

Hi Ayaphi,

I've turned our discussion into the issue – #237. So please let's move there :) I've provided new solution there for test.

Thanks,
Max