[tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list

This moves SoundFont processing to a common engine module which is connected to all sound font osc modules. This ensures that the data is ready when the modules are called, and process_fluid_L is only called once in the common module. The global soundfont lock problem should be solved by this PR.

Note that the sound_font_osc_process function still acquires the lock for a brief amount of time, but no audio generation takes place while the lock is held.


You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/85

Commit Summary

  • BSE: SF2: use shared engine module instead of global soundfont lock

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"BSE: SF2: use shared engine module instead of global soundfont lock (#85)"}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85", "url": "https://github.com/tim-janik/beast/pull/85", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } }, { "@type": "MessageCard", "@context": "http://schema.org/extensions", "hideOriginalBody": "false", "originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB", "title": "BSE: SF2: use shared engine module instead of global soundfont lock (#85)", "sections": [ { "text": "", "activityTitle": "**Stefan Westerfeld**", "activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png", "activitySubtitle": "@swesterfeld", "facts": [ ] }, { "title": "Commit Summary", "facts": [ { "name": "b3f2cbb", "value": "BSE: SF2: use shared engine module instead of global soundfont lock" } ] }, { "title": "File Changes", "facts": [ { "name": "Modified", "value": "[bse/bsesoundfontosc.cc](https://github.com/tim-janik/beast/pull/85/files#diff-0) (108 changes)" }, { "name": "Modified", "value": "[bse/bsesoundfontosc.hh](https://github.com/tim-janik/beast/pull/85/files#diff-1) (6 changes)" }, { "name": "Modified", "value": "[bse/bsesoundfontrepo.hh](https://github.com/tim-janik/beast/pull/85/files#diff-2) (1 changes)" } ] } ], "potentialAction": [ { "name": "Add a comment", "@type": "ActionCard", "inputs": [ { "isMultiLine": true, "@type": "TextInput", "id": "IssueComment", "isRequired": false } ], "actions": [ { "name": "Comment", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"tim-janik/beast\",\n\"issueId\": 85,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}" } ] }, { "name": "Close pull request", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"PullRequestClose\",\n\"repositoryFullName\": \"tim-janik/beast\",\n\"pullRequestId\": 85\n}" }, { "targets": [ { "os": "default", "uri": "https://github.com/tim-janik/beast/pull/85" } ], "@type": "OpenUri", "name": "View on GitHub" }, { "targets": [ { "os": "default", "uri": "https://github.com/tim-janik/beast/pull/85.patch" } ], "@type": "OpenUri", "name": "View patch" }, { "targets": [ { "os": "default", "uri": "https://github.com/tim-janik/beast/pull/85.diff" } ], "@type": "OpenUri", "name": "View diff" }, { "name": "Unsubscribe", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 395413005\n}" } ], "themeColor": "26292E" } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list

Recently, we discussed this merge request, and you (Tim) said you do not want to merge code that locks a mutex during audio processing due to priority inversion.

So, what does the lock protect here? There is one global fluid_synth instance that is used by both, the soundfont repo and the soundfont osc code. There is also a bunch of data shared between the soundfont osc modules that is protected by the lock. Locks are acquired

  • by the soundfont repo when loading/unloading soundfonts
  • by the soundfont osc modules when rendering audio

Like the wave repo code, we never load/unload soundfonts if the repo is prepared, so effectively the soundfont repo will not lock the global mutex while the project is playing.

The soundfont osc modules are

  • one common module that does the actual rendering (1)
  • per osc modules that just copy the data out, and maybe change the preset of the current voice (2)

But these modules are all executed within the engine process() callback so they effectively run with the highest priority we have. So there is no priority inversion possible here. Also note that while (1) takes a while because it renders the data, (2) is really cheap, because the audio data is already available.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swesterfeld in #85: Recently, we discussed this merge request, and you (Tim) said you do not want to merge code that locks a mutex during audio processing due to **priority inversion**.\r\n\r\nSo, what does the lock protect here? There is one global fluid_synth instance that is used by both, the soundfont repo and the soundfont osc code. There is also a bunch of data shared between the soundfont osc modules that is protected by the lock. Locks are acquired\r\n\r\n * by the soundfont repo when loading/unloading soundfonts\r\n * by the soundfont osc modules when rendering audio\r\n\r\nLike the wave repo code, we never load/unload soundfonts if the repo is prepared, so effectively the soundfont repo will not lock the global mutex while the project is playing.\r\n\r\nThe soundfont osc modules are\r\n * one common module that does the actual rendering (1)\r\n * per osc modules that just copy the data out, and maybe change the preset of the current voice (2)\r\n\r\nBut these modules are all executed within the engine process() callback so they effectively run with the highest priority we have. So **there is no priority inversion possible here**. Also note that while (1) takes a while because it renders the data, (2) is really cheap, because the audio data is already available."}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#issuecomment-484055853"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#issuecomment-484055853", "url": "https://github.com/tim-janik/beast/pull/85#issuecomment-484055853", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list
In reply to this post by Gnome - Beast mailing list

Recently, we discussed this merge request, and you (Tim) said you do not want to merge code that locks a mutex during audio processing due to priority inversion.

Engine modules must generally strive to finish their work in a predictable time period (soft realtime rendering) and not block for arbitrarily long periods. Examples that have to be avoided are:

  • Acquiring a mutex, since wait times for locks are not predictable.
  • Files must not be accessed from engine modules as this can also take arbitrarily long.
  • Filter table calculations (like approximation methods) also have to be moved out of engine modules.
  • Priority inversion (engine modules blocking on a lower priority thread) must be avoided;
  • Also, at the CPU / memory-bus level synchronization primitives are very expensive, so use of atomics/barriers should be avoided in engine modules if at all possible.
  • Also, mutexes and conditions are hard to reason about especially in an already complicated highly multi-threaded context like the engine. So other primitives like lock-free message queues should be used instead.

So priority inversion is just one of them.

Given the above set of limitations, implementing engine modules would be very hard. That's why we added engine-jobs that can be queued and processed (in a lock-free manner) on engine modules. The way that works is as follows:

  • Any state needed by an engine module is loaded/generated/computed in the BSE thread and wrapped by a callback into a closure that is enqueued on the corresponding engine module(s).
  • Before module processing, the jobs are executed in engine context and can update the module state as needed (without causing further allocations or using mutexes).
  • After job execution, the closure context is destroyed/deleted in the BSE thread.

So state that might ordinarily be synchronized between threads via a mutex should in the context of an engine module be reference-counted or copied and transferred into the engine module via a callback closure, without needing additional synchronization primitives.

So, what does the lock protect here? There is one global fluid_synth instance that is used by both, the soundfont repo and the soundfont osc code. There is also a bunch of data shared between the soundfont osc modules that is protected by the lock. Locks are acquired

* by the soundfont repo when loading/unloading soundfonts

* by the soundfont osc modules when rendering audio

Like the wave repo code, we never load/unload soundfonts if the repo is prepared, so effectively the soundfont repo will not lock the global mutex while the project is playing.

The soundfont osc modules are

* one common module that does the actual rendering (1)

* per osc modules that just copy the data out, and maybe change the preset of the current voice (2)

But these modules are all executed within the engine process() callback so they effectively run with the highest priority we have. So there is no priority inversion possible here. Also note that while (1) takes a while because it renders the data, (2) is really cheap, because the audio data is already available.

Why exactly is a mutex needed in the first place, let alone in an engine module?
As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.
Just to make sure that's understood, it is not ok for engine modules to be blocked while file IO ocours in another thread (like loading a soundfont).


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@tim-janik in #85: \u003e Recently, we discussed this merge request, and you (Tim) said you do not want to merge code that locks a mutex during audio processing due to **priority inversion**.\r\n\r\nEngine modules must generally strive to finish their work in a predictable time period (soft realtime rendering) and not block for arbitrarily long periods. Examples that have to be avoided are:\r\n\r\n- Acquiring a mutex, since wait times for locks are not predictable.\r\n- Files must not be accessed from engine modules as this can also take arbitrarily long.\r\n- Filter table calculations (like approximation methods) also have to be moved out of engine modules.\r\n- Priority inversion (engine modules blocking on a lower priority thread) must be avoided;\r\n- Also, at the CPU / memory-bus level synchronization primitives are very expensive, so use of atomics/barriers should be avoided in engine modules if at all possible.\r\n- Also, mutexes and conditions are hard to reason about especially in an already complicated highly multi-threaded context like the engine. So other primitives like lock-free message queues should be used instead.\r\n\r\nSo priority inversion is just one of them.\r\n\r\nGiven the above set of limitations, implementing engine modules would be very hard. That's why we added engine-jobs that can be queued and processed (in a lock-free manner) on engine modules. The way that works is as follows:\r\n- Any state needed by an engine module is loaded/generated/computed in the BSE thread and wrapped by a callback into a closure that is enqueued on the corresponding engine module(s).\r\n- Before module processing, the jobs are executed in engine context and can update the module state as needed (without causing further allocations or using mutexes).\r\n- After job execution, the closure context is destroyed/deleted in the BSE thread.\r\n\r\nSo state that might ordinarily be synchronized between threads via a mutex should in the context of an engine module be reference-counted or copied and transferred into the engine module via a callback closure, without needing additional synchronization primitives.\r\n\r\n\u003e So, what does the lock protect here? There is one global fluid_synth instance that is used by both, the soundfont repo and the soundfont osc code. There is also a bunch of data shared between the soundfont osc modules that is protected by the lock. Locks are acquired\r\n\u003e \r\n\u003e * by the soundfont repo when loading/unloading soundfonts\r\n\u003e \r\n\u003e * by the soundfont osc modules when rendering audio\r\n\u003e \r\n\u003e \r\n\u003e Like the wave repo code, we never load/unload soundfonts if the repo is prepared, so effectively the soundfont repo will not lock the global mutex while the project is playing.\r\n\u003e \r\n\u003e The soundfont osc modules are\r\n\u003e \r\n\u003e * one common module that does the actual rendering (1)\r\n\u003e \r\n\u003e * per osc modules that just copy the data out, and maybe change the preset of the current voice (2)\r\n\u003e \r\n\u003e \r\n\u003e But these modules are all executed within the engine process() callback so they effectively run with the highest priority we have. So **there is no priority inversion possible here**. Also note that while (1) takes a while because it renders the data, (2) is really cheap, because the audio data is already available.\r\n\r\nWhy exactly is a mutex needed in the first place, let alone in an engine module?\r\nAs stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.\r\nJust to make sure that's understood, it is *not* ok for engine modules to be blocked while file IO ocours in another thread (like loading a soundfont). "}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#issuecomment-484099589"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#issuecomment-484099589", "url": "https://github.com/tim-janik/beast/pull/85#issuecomment-484099589", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list
In reply to this post by Gnome - Beast mailing list

Why exactly is a mutex needed in the first place, let alone in an engine module?

Because multiple engine modules share state, especially because multiple engine module access the same fluid_synth_t instance, and could (possibly) call API functions on the same fluid synth instance at the same time.

As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.

I agree that ultimately the solution I submitted is not perfect.

To avoid long discussions, I'll try to put more work into this branch and resubmit a new version that can hopefully do this without lock.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swesterfeld in #85: \u003e Why exactly is a mutex needed in the first place, let alone in an engine module?\r\n\r\nBecause multiple engine modules share state, especially because multiple engine module access the same fluid_synth_t instance, and could (possibly) call API functions on the same fluid synth instance at the same time.\r\n\r\n\u003e As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.\r\n\r\nI agree that ultimately the solution I submitted is not perfect.\r\n\r\nTo avoid long discussions, I'll try to put more work into this branch and resubmit a new version that can hopefully do this without lock."}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#issuecomment-484164598"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#issuecomment-484164598", "url": "https://github.com/tim-janik/beast/pull/85#issuecomment-484164598", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list
In reply to this post by Gnome - Beast mailing list

Why exactly is a mutex needed in the first place, let alone in an engine module?

Because multiple engine modules share state, especially because multiple engine module access the same fluid_synth_t instance, and could (possibly) call API functions on the same fluid synth instance at the same time.

In that case, there should be one engine module around the fluid_synth_t instance, and the other modules should connect to this one module as input.

As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.

Can we get rid of the shared state once the fixed fluidsynth 2.0.5 is out, or is this unrelated?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@tim-janik in #85: \u003e \u003e Why exactly is a mutex needed in the first place, let alone in an engine module?\r\n\u003e \r\n\u003e Because multiple engine modules share state, especially because multiple engine module access the same fluid_synth_t instance, and could (possibly) call API functions on the same fluid synth instance at the same time.\r\n\u003e \r\n\r\nIn that case, there should be *one* engine module around the fluid_synth_t instance, and the other modules should connect to this one module as input.\r\n\r\n\u003e \u003e As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.\r\n\r\nCan we get rid of the shared state once the fixed fluidsynth 2.0.5 is out, or is this unrelated?"}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#issuecomment-484286150"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#issuecomment-484286150", "url": "https://github.com/tim-janik/beast/pull/85#issuecomment-484286150", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list
In reply to this post by Gnome - Beast mailing list

In that case, there should be one engine module around the fluid_synth_t instance, and the other modules should connect to this one module as input.

Yes, this PR does about half of what you ask; it uses one shared engine module around the fluid_synth_t instance (good), but on the other hand accesses the fluid_synth_t instance from all engine modules (bad), so it still needs a lock. It could be fixed in this PR, but I now believe it is better to use a different approach; on fluid_synth_t instance per osc, as submitted in #102

As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.

Can we get rid of the shared state once the fixed fluidsynth 2.0.5 is out, or is this unrelated?

This is unrelated. Using fluidsynth 2.0.5 mainly allows us to fix the deprecation warning.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swesterfeld in #85: \u003e In that case, there should be _one_ engine module around the fluid_synth_t instance, and the other modules should connect to this one module as input.\r\n\r\nYes, this PR does about half of what you ask; it uses one shared engine module around the fluid_synth_t instance (good), but on the other hand accesses the fluid_synth_t instance from all engine modules (bad), so it still needs a lock. It could be fixed in this PR, but I now believe **it is better to use a different approach; on fluid_synth_t instance per osc**, as submitted in https://github.com/tim-janik/beast/pull/102\r\n\r\n\u003e \u003e \u003e As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.\r\n\u003e \r\n\u003e Can we get rid of the shared state once the fixed fluidsynth 2.0.5 is out, or is this unrelated?\r\n\r\nThis is unrelated. Using fluidsynth 2.0.5 mainly allows us to fix the deprecation warning."}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#issuecomment-485841233"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#issuecomment-485841233", "url": "https://github.com/tim-janik/beast/pull/85#issuecomment-485841233", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list
In reply to this post by Gnome - Beast mailing list

Stefan, can we close this in favor of #102 ?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@tim-janik in #85: Stefan, can we close this in favor of #102 ?"}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#issuecomment-487701243"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#issuecomment-487701243", "url": "https://github.com/tim-janik/beast/pull/85#issuecomment-487701243", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list
In reply to this post by Gnome - Beast mailing list

Closed #85.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"Closed #85."}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#event-2308859385"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#event-2308859385", "url": "https://github.com/tim-janik/beast/pull/85#event-2308859385", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

Gnome - Beast mailing list
In reply to this post by Gnome - Beast mailing list

Stefan, can we close this in favor of #102 ?

Yes, I'm closing this PR now.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swesterfeld in #85: \u003e Stefan, can we close this in favor of #102 ?\r\n\r\nYes, I'm closing this PR now."}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/85#issuecomment-487871637"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/85#issuecomment-487871637", "url": "https://github.com/tim-janik/beast/pull/85#issuecomment-487871637", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast