I develop on an old 2009 macbook, and it runs silky smooth, but it is a bit slow on my 2014 Chromebook.

Zooming in/out should not impact midi. Could you open the console ctrl ., see if there isn’t any error? Maybe run the performance tab, see where the bottleneck is.

Orca-c is not abandoned, I think last change was yesterday? I just need help with it, I’m spread a bit thin.

Maybe it’s a retina type issue, press back tick(character left of 1 key), that will toggle off upscale if your screen is retina.

Sample folder selection is now functional :slight_smile: File > Select Sample Folder I’ll add shortcut and persistence later, I have a few things I want to get done first.

1 Like

Thanks alot for your fast and kind reply! No worries regarding Orca-c, Just wanted to make sure that I was right in not using that instead…

When starting orca I get this in the terminal:

    > Orca@0.1.0 start /mnt/data/atte/medium/software/orca/git/desktop
    > electron .
    Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
    Unable to revert mtime: /usr/local/share/fonts
    Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

And a bit later:

[15401:0602/144735.112219:ERROR:CONSOLE(24)] "Empty response arrived for script 'chrome-devtools://devtools/remote/serve_file/@7154f3777129c2f32d160297120b6e200ec29830/product_registry_impl/product_registry_impl_module.js'", source: chrome-devtools://devtools/bundled/shell.js (24)
[15401:0602/144735.118965:ERROR:CONSOLE(108)] "Uncaught (in promise) Error: Could not instantiate: ProductRegistryImpl.Registry", source: chrome-devtools://devtools/bundled/shell.js (108)
[15401:0602/144735.119088:ERROR:CONSOLE(108)] "Uncaught (in promise) Error: Could not instantiate: ProductRegistryImpl.Registry", source: chrome-devtools://devtools/bundled/shell.js (108)
[15401:0602/144735.119247:ERROR:CONSOLE(108)] "Uncaught (in promise) Error: Could not instantiate: ProductRegistryImpl.Registry", source: chrome-devtools://devtools/bundled/shell.js (108)
[15401:0602/145416.128182:ERROR:CONSOLE(24)] "Empty response arrived for script 'chrome-devtools://devtools/remote/serve_file/@7154f3777129c2f32d160297120b6e200ec29830/product_registry_impl/product_registry_impl_module.js'", source: chrome-devtools://devtools/bundled/shell.js (24)
[15401:0602/145416.134333:ERROR:CONSOLE(108)] "Uncaught (in promise) Error: Could not instantiate: ProductRegistryImpl.Registry", source: chrome-devtools://devtools/bundled/shell.js (108)
[15401:0602/145416.135812:ERROR:CONSOLE(108)] "Uncaught (in promise) Error: Could not instantiate: ProductRegistryImpl.Registry", source: chrome-devtools://devtools/bundled/shell.js (108)
[15401:0602/145416.135964:ERROR:CONSOLE(108)] "Uncaught (in promise) Error: Could not instantiate: ProductRegistryImpl.Registry", source: chrome-devtools://devtools/bundled/shell.js (108)

Pretty sure my screen is not retina (isn’t that a mac thing)? It’s an old lenovo… toggling upscale didn’t change anything…

I tried “ctrl .”, I see no errors, here’s the preformance test:

1000ms of code execution over 4.65 seconds is, really really poor performance. If you know how to dig through the performance tool and see which function causes this hold up, let me know. But it’s not looking good.

I get 50ms code execution over 5 seconds, to give you an idea.

Thanks! Good to know something is wrong!

It seems to me that something is configured, probably in relation to orca (or dependencies), know it’s an entirely different task, but I routinely record and mix 24 track audio on this box, with no glitches…

I’m not sure how to work the performance measurements, but here are a few screenshots, does this give you a hint on where I should look?




Other suggestions?

Looks like it’s spending alot of time in Terminal.drawSprite and ipcRenderer.sendSync…

EDIT: I’d be really interested in hearing how orca performs on other linux boxes! Anyone?

1 Like

How big is your screen exactly?

FWIW - on raspberry pi (Raspbian) the Electron version runs, but any menu commands crash the app. (Have not really debugged this at all tho)

Thus I’m using Orca-c instead

1680x1050 on the desktop box…

I investigated general electron performance on linux, and somewhere someone hinted that disabling hardware acceleration would help.

I hacked this into index.html:

app.disableHardwareAcceleration()

The orca display screen is just black, so not sure what’s running, but the performance is stellar:

Could this be a viable route? If so, I’d love to test out a version of orca without hardware acceleration!!!

Ok, sound promising! I’d love to run that. However, seems the language is missing a lot of stuff in Orca-c (or I messed up the build).

EDIT: orca-c, doesn’t appear to be far behind language-wise (the help is really nice in electron orca, though), I’m typing in both versions, to compare. Seems like the best way forward for me ATM is orca-c!

1 Like

Yes - I believe orca-c is behind in functionality (most recent ops, etc)

I’m still in the “getting started” phases so can’t really compare yet.

I think the menu crashes will be related to electron more than orca itself. Would be interesting to investigate at some point :slight_smile:

1 Like

Sweet! But i’m not clear on how to install and use this? Pilot and Orca are apps and are installed that way. What am I doing wrong?

1 Like

It’s not yet released as an App but there’s instructions on the github on how to run it.

But I will package it as an app next week for everyone that prefer to have apps :slight_smile:

It’s in heavy development (I started it 3 days ago! ), it’s getting a visual facelift at the moment!

Sneak peak: it’s getting a familiar looking editor

5 Likes

yeah my CLI skills are srsly lacking, I crapped out at NPM install. :slight_smile: I will wait for the app release. Super exciting! Thanks

1 Like

did you mean 0-9 are unused after my suggestion for pitch/sustain or that they’re currently the only unused operators? Given each midi control has an octave parameter, I think using them for that would make things confusing. I think making/keeping 0 as a ‘dead’ operator makes sense, as sort of an alternative way to comment. That leaves 1-9, Maybe mapping these to a second midi device would be nice? that would bump the possible MIDI channel count from 16 to 24. Another option would be to use them for sending a MIDI clock to an external program, but I’m not sure that makes sense as an operator or if it should just be done by default when the midi device is selected. Finally, going along with the idea of multiple devices, they could be used to select which device other midi operators are using, something along the lines of :[device][channel][octave][vel][len] where :1.... would say “all midi operators use the first devices” :12... is “all midi operators on channel 2 use the first device” :123.. would be “all midi operator on channel 2, playing in the 3rd octave, use the 1st device” , etc.

I don’t really know what the best option is, but hopefully this gives you a few ideas.

1 Like

Yeah, after some thoughts I think I will leave the numbers alone, or maybe have them transpose to an octave down. Example

:039 # 2G
:038 # 2F

Messing around

In other news, I’ve managed to get Orca paired with the BBC Microbit as synthesizer. Also, I pushed an update today that improves the UDP support. I might get a second one and make a tiny polyphonic synth for the road.

1 Like

Quick question: What’s the “meter” in the lower part of the screen indicating in orca-c?

It show the number of input/output messages for that frame, it combines UDP, OSC and Midi messages.

2 Likes

Ok, thanks.

So I shouldn’t worry if it’s maxing the meter out per se?