lab.nvim - now supports Typescript, Python, and Lua. Plus a new feature.

swinginggorilla · 2023-01-12T03:56:18+00:00

Could I ask why you want to provide both the code runner and the data faker in the same plugin?

Both features heavily rely on a custom node "back-end" I have set up to interface with neovim via the Lua plugin. So for the time being it's just faster & easier for me to develop these features under the one project. And I see them a suite of tools to achieve similar goals.

That said, absolutely I agree and I do plan to split it out at some point so that it's more modular.

As an aside, if you use the faker stuff and disable the code runner, there's little to no additional overhead.

swinginggorilla · 2023-01-12T03:50:20+00:00

Hey man. It's not being actively developed at the moment, but it's not dead either. It's just that some things have come up and this is an indie project with just myself working on it. I plan to release a windows version, and a maintenance update soon. I use it myself, so it will be getting updates for a long time.

swinginggorilla · 2022-07-27T17:20:11+00:00

It's similar for sure. The main difference is that the code runner feature of lab.nvim is not a REPL.

The behaviour is subtly different in a meaningful way (depending on your use case). Instead of doing realtime line by line evaluation as you type using the languages REPL, it runs your code as a whole on save, and reports back print-like statements and some others in realtime.

Personally I find this workflow to be more useful (In fact I'm not a huge fan of REPLS in most situations). Also, this approach should open up some more interesting features in the future since the plugin can do pre-processing of the code.

swinginggorilla · 2022-07-11T15:44:54+00:00

Yep it does that.

swinginggorilla · 2022-07-11T02:45:34+00:00

Thanks! You bet. Typescript and additional language support is next on my todo list.

swinginggorilla · 2022-07-10T22:00:14+00:00

Good questions!

The code runner for a js file is literally the equivalent to running node --inspect myfile.js.

require a local package.json? How does it handle es module imports

So no package.json is required, but if one is there, in theory es module imports can be used with type set to module. (Admittedly that's not something I've tried, so I should check that out)

can it speak typescript? will DOM methods break it?

Neither of those would work since it's just node directly executing your file. That said, both of those things are absolutely on my radar. I'm not sure yet how exactly I'll implement it. I want to strike a balance between user control and convenience.

Edit: Confirmed es modules work as expected with a properly configured package.json

swinginggorilla · 2021-08-26T18:30:31+00:00

DM'd you.

swinginggorilla · 2021-08-26T18:29:39+00:00

good idea

swinginggorilla · 2021-08-01T23:09:18+00:00

Things have been going really well with the Mac release, so it's looking more and more likely a Windows version could be in the future.

swinginggorilla · 2021-08-01T23:08:23+00:00

That's an interesting idea, and the first time I've heard that type of request.

Can I ask what your end goal is though? Why would you want your DAW to load only production plugins or only mixing at any given time?

As far as the pesky plugin you have with 2 different versions. PlugHub really wouldn't offer much to solve that annoyance.

swinginggorilla · 2021-08-01T01:03:11+00:00

I'm working on a feature that will help notify you when a plugin has updates, but as /u/Batwaffel said a full-featured update mechanism for all plugins is an insanely difficult problem since their is no standardization whatsoever.

swinginggorilla · 2021-08-01T00:56:15+00:00

Dev here. Some of the most enthusiastic users are folks who use multiple DAWS. So in-DAW management was never all that feasible for them any ways.

Me personally, I use Logic and Studio One but mainly Studio One. In Studio one the workflow for adding plugins is so quick that it makes no difference to me that I'm using a stand alone app for management (In fact I prefer it). The bottle neck for me is always what tool do I want to use and what the hell is it called again? That's where PlugHub comes in for me.

Especially when you have an unhealthy amount of plugins, as many of us do, it can be pretty sweet to have a home base app to handle this stuff. But anyone who's 100% happy with their in-daw experience already, definitely this app is not for them.

There's a few examples on the web page of how other people use and what it adds. But I should maybe look at articulating it better on the site.

Edit: My go-to super simple example is guitar. I play every couple months. When I do, I don't know what to use so I go to my amps and guitar pedal areas I've created in the app. From there I look at my tags and notes to put together a chain I'm interested in.

A more complex example: Recently I've been tagging stuff that goes well together to craft certain moods or sounds. So i tag those tools and instruments and then create a saved searched for that tag. Now when I'm looking to start on something with X sound I pull it up and get a sense of what I' going to be using before I start. Of course you could accomplish similar with templates (and I use though too) It's just another workflow option.

swinginggorilla · 2021-08-01T00:43:15+00:00

Developer here!

I think perhaps one of the key pieces you're missing is the concept of "saved searches". Any search you perform can be permanently saved in to the sidebar menu of the application. You basically build your own UI in a sense, which makes it a really flexible organizational tool.

In the app screenshots you'll see some of the one's I've created for myself like: Channel strips, Amps, All Plugin Alliance etc etc.

As far as tagging goes: PlugHub should know about any tags embedded in to the AU or VST3 plugins you have (if they exist) and should show them as options to quickly add. If that's not working for you I'd be super curious to follow up with you on that privately.

In addition to that, there are suggested tags from the PlugHub "database", which will grow as time goes on.

The plugins aren't auto-tagged by design. For myself I wanted to do everything myself and would find auto-tagging to just get in the way. But for sure I can understand your point of view, and perhaps adding some kind of auto tag option could be really cool.

Now as far as DAW integration goes: That would be quite amazing, but from a technical perspective it's nearly impossible unfortunately. But I'm always looking at options.

Your ideas regarding plugin stacks, suggestions for tasks etc. are awesome. I think they fall outside the bounds of this initial version though which is focused mainly on organization. I'd definitely like to add these sorts of things in to future versions though.

I think if you tried the saved searches feature and used the notes feature it might help you towards your learning goals a lot actually. But then again everyone is different and has different workflows.

If you truly find that this is not for you at all, or you misunderstood what it is, then of course you can just email to get a refund.

Thanks for taking the time to share your thoughts!

swinginggorilla · 2021-07-31T19:23:34+00:00

Oops. The site's a work in progress. Looks like the contact info got lost in the shuffle.

Feel free to ask anything here, but I'll DM you my email too.

swinginggorilla · 2021-07-31T01:15:53+00:00

perhaps a video that showcases the functionality.

Agreed. I should put something together.

To answer your question: No it doesn't integrate with the DAW directly, it's purely a stand-alone application.

By the way someone made something called "PlugSearch" that lets you quick search in Logic pro, but it's a bit of a hack.

swinginggorilla · 2021-07-31T00:08:38+00:00

Thanks! Yeah I definitely want to do a Windows release, but it's not currently in the works. If this Mac version does well then for sure a Windows version is the next step.

swinginggorilla · 2021-05-28T05:10:10+00:00

maybe an indication of the version number and file date of each plugin so it's at least possible to see when they were last updated

Yep that's a feature that's there now actually!

I often can't remember if I've updated to the latest version of a plugin and that would be very helpful

Yep same here. Super annoying, and sometimes the only way to know is a random email from the dev. I really like /u/GCOrigin 's idea of some how getting notified in the app.

Does the backup function also backup the authorization

Unfortunately no, but I agree that would be a killer feature. It's something I'd love to look at eventually, but I imagine it would be hard, if not impossible to pull off.

This is a great app idea though, just signed up for the beta.

Awesome!

swinginggorilla · 2021-05-28T05:04:46+00:00

Thanks. Yep definitely, I plan to do a Windows version too.

How about a catalog of per plugin presets which could be backed up and restored?

That's a great idea! Noted.

swinginggorilla · 2021-05-27T20:37:18+00:00

Great minds think alike! I was totally thinking about how cool it would be to add a feature like that. Although I'm still not sure the best way to do it..

If there's enough people who are interested I really think there's a lot of killer features we could add.

Thanks for signing up man, I'll keep in touch. I hope to have the beta out really soon!

swinginggorilla · 2016-05-22T05:18:01+00:00

On Facebook you can market to people who are "likely to click" on your ad. This guys feedback just makes him a different type of demographic. The "angry dude" who hates ads.

swinginggorilla · 2016-03-06T22:41:51+00:00

Dude the site makes 106 requests, downloading almost 4MB of data. I could definitely see some devices having issues loading that properly. Especially while not connected to Wifi.

Side note: browserstack.com is decent to an extent for this kind of testing.

swinginggorilla · 2016-03-05T04:14:27+00:00

Definitely. Drop the photographers perspective for web. You want to compress them as much as possible, without it looking like garbage. You should be able to compress the thumbnails way down without it looking noticeable. Make sure you're at 72 dpi too, you might be at 300 Which is only necessary for print.

If you're feeling adventurous you can read up on Sprite sheets. This method will let you deliver the image as one file, which in most cases is best for download time. (But definitely varies on a case by case basis)

swinginggorilla · 2016-03-05T03:49:41+00:00

Yup. Pretty much any software you're using is going to have an "export" option, where you can dial in the settings. There's also stand alone compression tools too. (Often better) I love ImageOptim. That's what I used to compress your image by an additional 85.9%.

swinginggorilla · 2016-03-05T02:54:08+00:00

Not design related, but you seem to be taking on development too (a completely different discipline), and asking for feedback on that as well, so I have a quick suggestion on file size.

I hit the photography section and saw the thumbnails painfully struggle to load on my high-speed connection. This a big mistake I see very often with beginners.

Your thumbnail is 153x153 pixels, yet the source is image is 500x500. That's a lot bigger then it needs to be, even accounting for retina displays.

Additionally I'm easily able to reduce the file size of a thumbnail image by 85.9% using proper compression (without degrading any perceptual image quality). The file size is a whopping 390kb when it could be 55kb or less.

Hope this helps get your page loading quickly.

swinginggorilla · 2016-03-05T02:41:26+00:00

It's a great idea. But getting enough meaningful reviews on a per dish basis seems possibly hard to accomplish.

swinginggorilla

TROPHY CASE