Replies: 9 comments 9 replies
-
|
That's odd. On Node.js, WEBMIDI.js falls back on the jzz library which handles all MIDI communication with the host instead of the Web MIDI API used in browsers. Perhaps you could try that library and see if you get the same issue. If you do, then the problem is probably on the What differences are there between your MacBook and the Mac Pro? (OS, CPU, browser, versions, etc.) |
Beta Was this translation helpful? Give feedback.
-
|
I can try jzz, but I do remember you saying somewhere that enable() may take "a while". how long would you expect it to take? There are no diffs in config of the MacBook and the Mac Pro, other than of course the Mac Pro has many more cores, etc. but OS, browser, versions, etc are all identical. Opening a channel and actually sending midi are instantaneous, it's literally just waiting for the enable() promise to resolve that's taking forever. any thoughts on what it coudl be before i switch to trying jzz? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not suggesting you switch to Normally, initialization should take less than 3 seconds. |
Beta Was this translation helpful? Give feedback.
-
|
ok, got it. so let me know if this is normal. I do have a lot of midi devices on the production machine (midi is the messaging hub of my studio). the dev machines do NOT have many midi devices (1 or 2), so enable resolves quickly. The promise returns quickly from enable(), it's just that it is taking 4.8 seconds to resolve the promise. During that time, other port operations on the mac are blocked (for instance, opening serial ports, etc). I have about 20 midi devices (enabled or disabled) on the prod machine. Would that explain it taking 4.8 seconds to resolve the promise? (again, the promise does always get resolved, just after the lengthy time where other port operations are blocked). I don't know what's going on under the hood during the asynchronous part of enable, but let me know if this would explain things or if there's something else I should be looking at? Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
It's possible that it takes longer due to the number of devices. I have never tried it with so many devices. It's quite a setup you've got there! If you leave only a single device connected, does |
Beta Was this translation helpful? Give feedback.
-
|
whoa, so just found a bigger problem with either WebMidi/jzz, so haven't
even gotten around to debuggin why enable takes so long. Let's say I make
a call to WebMidi.enable() and then do absolutely nothing else with WebMidi
for the entire process (process has an express server, so basically stays
runnign all the time). There is some crazy memory leak in the underlying
library such that it ate through 64 GB of memory in about 2 days....
literaly calling enable() and then doing absolutely nothing else.
Thoughts?
Thanks
…On Tue, Aug 6, 2024 at 8:42 AM Jean-Philippe Côté ***@***.***> wrote:
It's possible that it takes longer due to the number of devices. I have
never tried it with so many devices. It's quite a setup you've got there!
If you leave only a single device connected, does enable() resolve faster?
—
Reply to this email directly, view it on GitHub
<#426 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGJFGXSDQX6ZCM3VWPGYLZQDVIDAVCNFSM6AAAAABMBDJTW6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRVGU2DKMA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's very hard to tell what's going on without seeing the actual code. Do you have a barebones example that triggers the problem (I guess it needs Express)? I'd like to run it on my end to try and identify the problem. |
Beta Was this translation helpful? Give feedback.
-
|
Hello,
I'm sorry about the delay, i had a family issue come up.
Anyways, I would be extremely appreciative if you had any advice on this
memory issue. Here is a barebones script that simply runs an express
server with a send-midi endpoint, and sends the midi.
Note that I get HUGE memory leaks simply from letting this server run, even
if i'm not making any calls at all to it.
Any advice would be appreciated, and thanks!
const express = require('express');
const { WebMidi } = require('webmidi');
// Initialize the app
const app = express();
const port = 3001;
// Middleware to parse JSON request bodies
app.use(express.json());
// Enable WebMidi
WebMidi.enable((err) => {
if (err) {
console.error('WebMidi could not be enabled.', err);
return;
}
console.log('WebMidi enabled.');
});
// Route to send MIDI messages
app.post('/send-midi', (req, res) => {
const { deviceName, channel, note, velocity, action } = req.body;
// Validate required fields
if (!deviceName || !channel || !note || !action) {
return res.status(400).json({ error: 'Missing required fields' });
}
// Get the output device by name
const output = WebMidi.getOutputByName(deviceName);
if (!output) {
return res.status(404).json({ error: `MIDI device "${deviceName}" not found`
});
}
// Send the appropriate MIDI message
try {
if (action === 'noteon') {
output.channels[channel].playNote(note, { velocity });
} else if (action === 'noteoff') {
output.channels[channel].stopNote(note);
} else {
return res.status(400).json({ error: `Unsupported action "${action}"` });
}
res.json({ success: `MIDI message sent: ${action} ${note} on channel ${
channel}` });
} catch (err) {
res.status(500).json({ error: 'Error sending MIDI message', details: err.
message });
}
});
// Start the server
app.listen(port, () => {
console.log(`MIDI server running at http://localhost:${port}`);
});
…On Sat, Aug 10, 2024 at 5:43 AM Jean-Philippe Côté ***@***.***> wrote:
It's very hard to tell what's going on without seeing the actual code. Do
you have a barebones example that triggers the problem (I guess it needs
Express)? I'd like to run it on my end to try and identify the problem.
—
Reply to this email directly, view it on GitHub
<#426 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGJFHNJEPAO3R67OB5S63ZQYDHLAVCNFSM6AAAAABMBDJTW6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRZG4YTOMY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I ran your example on my MacBook this morning. Over the course of 4 hours, the memory went from 22MB to 51MB. This boils down to about 6-7MB per hour of memory leak, which is definitely abnormal. However, it is still not clear to me where the leak comes from. I will run a similar code sample that only uses the |
Beta Was this translation helpful? Give feedback.
-
|
one more thing on this: on my studio machine (with TONS of midi
interfaces), this script seems to bleed like 100MB//minute which is why I
caught the issue. But even on my laptop with 0 midi interfaces (other than
IAC), it's bleeding about 5MB / minute, so, much less, but shows there's
some leak somewhere, just made more extreme with all the midi interfaces on
my studio machine. (Note that if I comment out the call to
WebMidi.enable(), there's no bleeding, so it's not express. I'm not
familiar enough with the WebMidi or jzz code to debug this, but please let
me know any thoughts.
Thanks!
…On Wed, Aug 21, 2024 at 2:32 PM Brian Singerman ***@***.***> wrote:
Hello,
I'm sorry about the delay, i had a family issue come up.
Anyways, I would be extremely appreciative if you had any advice on this
memory issue. Here is a barebones script that simply runs an express
server with a send-midi endpoint, and sends the midi.
Note that I get HUGE memory leaks simply from letting this server run,
even if i'm not making any calls at all to it.
Any advice would be appreciated, and thanks!
const express = require('express');
const { WebMidi } = require('webmidi');
// Initialize the app
const app = express();
const port = 3001;
// Middleware to parse JSON request bodies
app.use(express.json());
// Enable WebMidi
WebMidi.enable((err) => {
if (err) {
console.error('WebMidi could not be enabled.', err);
return;
}
console.log('WebMidi enabled.');
});
// Route to send MIDI messages
app.post('/send-midi', (req, res) => {
const { deviceName, channel, note, velocity, action } = req.body;
// Validate required fields
if (!deviceName || !channel || !note || !action) {
return res.status(400).json({ error: 'Missing required fields' });
}
// Get the output device by name
const output = WebMidi.getOutputByName(deviceName);
if (!output) {
return res.status(404).json({ error: `MIDI device "${deviceName}" not
found` });
}
// Send the appropriate MIDI message
try {
if (action === 'noteon') {
output.channels[channel].playNote(note, { velocity });
} else if (action === 'noteoff') {
output.channels[channel].stopNote(note);
} else {
return res.status(400).json({ error: `Unsupported action "${action}"` });
}
res.json({ success: `MIDI message sent: ${action} ${note} on channel ${
channel}` });
} catch (err) {
res.status(500).json({ error: 'Error sending MIDI message', details: err.
message });
}
});
// Start the server
app.listen(port, () => {
console.log(`MIDI server running at http://localhost:${port}`);
});
On Sat, Aug 10, 2024 at 5:43 AM Jean-Philippe Côté <
***@***.***> wrote:
> It's very hard to tell what's going on without seeing the actual code. Do
> you have a barebones example that triggers the problem (I guess it needs
> Express)? I'd like to run it on my end to try and identify the problem.
>
> —
> Reply to this email directly, view it on GitHub
> <#426 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABGJFHNJEPAO3R67OB5S63ZQYDHLAVCNFSM6AAAAABMBDJTW6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRZG4YTOMY>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
|
awesome, thanks so much for your help! The example is as minimal as it
gets, so appreciate the testing out. thanks
…On Mon, Sep 16, 2024 at 11:12 AM Jean-Philippe Côté < ***@***.***> wrote:
I ran you example on my MacBook this morning. Over the course of 4 hours,
the memory went from 22MB to 51MB. This boils down to about 6-7MB per hour
of memory leak, which is definitely abnormal.
However, it is still not clear to me where the leak comes from. I will run
a similar code sample that only uses the jzz module to try and identify
where the problem lies. I'll keep you posted.
—
Reply to this email directly, view it on GitHub
<#426 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGJFCQE23LZ5AZXSRM4T3ZW4NRFAVCNFSM6AAAAABMBDJTW6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRWGI3TGMY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
My tests seem to show that the problem lies with the I created an issue on the For reference, here is the code I used to trigger the problem: const express = require('express');
const navigator = require('jzz');
// jzz
navigator.requestMIDIAccess({sysex: true}).then(
() => console.log("MIDI Started"),
() => console.log("MIDI Failed"),
);
// express
const app = express();
app.post('/test', (req, res) => {
res.json({ success: `Yeah!` });
});
app.use(express.json());
app.listen(3001, () => console.log("Express Listening...")); |
Beta Was this translation helpful? Give feedback.
-
|
I also created an issue on this repo to make sure I don't forget to follow up with the |
Beta Was this translation helpful? Give feedback.
-
|
Excellent, thanks for reporting this. Note that this of course is not just server side of course (even thought express is used).
Thanks for following up
… On Sep 16, 2024, at 17:48, Jean-Philippe Côté ***@***.***> wrote:
I also created an issue <#432> on this repo to make sure I don't forget to follow up with the jzz crew.
—
Reply to this email directly, view it on GitHub <#426 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGJFB5ASLQXXDAAHLY2P3ZW537VAVCNFSM6AAAAABMBDJTW6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRWGUYTMMI>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure what you mean. Are you saying this happens in the browser too? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, i meant that the script I’m using is for a local process running on the Mac. Not using browser at all, just explaining why midi is being used here (as per the comment on the jzz project issue) as it wouldn’t make sense for a pure server side process to be scanning midi ports.
…________________________________
From: Jean-Philippe Côté ***@***.***>
Sent: Tuesday, September 17, 2024 4:48:53 AM
To: djipco/webmidi ***@***.***>
Cc: briansin ***@***.***>; Author ***@***.***>
Subject: Re: [djipco/webmidi] WebMidi.enable() taking a long time (Discussion #426)
I'm not sure what you mean. Are you saying this happens in the browser too?
—
Reply to this email directly, view it on GitHub<#426 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AABGJFEFBNNN4PC4GULSH2DZXAJKLAVCNFSM6AAAAABMBDJTW6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRWHE3TEMY>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I could totally see a scenario where remote users could trigger local devices but I digress... 🙂 Regarding your issue, while waiting for a fix to As far as I know, there is no memory issue with WEBMIDI.js when it's run inside the browser. In this scenario, |
Beta Was this translation helpful? Give feedback.
-
|
Yes, understood. I thought about that but I have many scripts meant to run my studio. All these scripts basically convert http (local) into whatever the piece of studio gear needs (midi, rs232 serial port, i2c, other archaic protocols) so I can have a main dashboard control all this stuff via normal get/post methods (hence the local express server). So running the bridges themselves (bridge between http and the other protocols) doesn’t make much sense in a browser unfortunately.
I appreciate the help in getting either jzz or webmidi to not leak memory. Was hoping not to have to do all this stuff in swift instead since it’s so much easier in node for me.
Thank you!
… On Sep 17, 2024, at 07:47, Jean-Philippe Côté ***@***.***> wrote:
I could totally see a scenario where remote users could trigger local devices but I digress... 🙂
Regarding your issue, while waiting for a fix to jzz, you could decide to run your code in a "local" browser via a framework such as Electron <https://www.electronjs.org/> or NW.js <https://nwjs.io/>.
As far as I know, there is no memory issue with WEBMIDI.js when it's run inside the browser. In this scenario, jzz is not involved at all. The only reason jzz is used is to provide a MIDI layer when running through Node.js.
—
Reply to this email directly, view it on GitHub <#426 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGJFEBXF4KTJ5C2FLZF4LZXA6HJAVCNFSM6AAAAABMBDJTW6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRXGE3DKNI>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
-
Hello, apologies for the new question. In my dev environment (Macbook Pro), the promise from WebMidi.enable() was resolved almost instantly. Great!
On my prod Mac Pro, it has taken 5-10 seconds. It always resolves, it just takes a lot longer there for some reason. Is this normal? Is there something in my environment on that machine that is making it take longer to resolve?
Note this is from a node script, not browser based.
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions