Hacker Newsnew | past | comments | ask | show | jobs | submit | lukaszkorecki's commentslogin

I need to check this out, I bounced off Max 3 times now because I find the GUI approach so tedious

Max itself can be manipulated through JavaScript. You can dynamically create and connect objects in it, set scheduler tasks, etc. Max goes a lot deeper than wiring some GUI boxes together.

Have a dig around here: https://docs.cycling74.com/apiref/js/


There's a big caveat there though that is widely misunderstood. Max has separate scheduler and UI threads. JS only runs in the UI thread, and thus cannot be used for reliable timing tasks - timing will seem to be ok until there is load and than the UI thread timing is out the window.

One of the main reasons I wrote Scheme for Max (S4M) was to enable tightly timed scripting. You can pick which thread an S4M instance runs in, and each instance is totally isolated, which is very different model from the Max js objects (including the new V8) one. Those are global and only in the UI thread. S4M works very well for this, I use it in Max for Live and can get it synchronized perfectly underload with other sequencers.

I started scripting max with JS and built Scheme for Max after banging into its limitations. My typical workflow is a mix of Max, Csound in Max, Gen and Scheme, with the fast majority of the work happening in Scheme.


Well, it's obviously not intended for realtime 'live coding', but as an answer to the problem of dealing with the GUI and manually cabling a patch up it suffices, though it does help to be fairly conversant with the basics of Max to begin with. For instance I've used JS to auto-populate a patch where the number of abstractions isn't known in advance and may need to change, with each abstraction then getting its own settings passed as generated arguments. It could be a nightmare cable spaghetti patch but JS made it end up very neat and tidy.

IMO there are far better options for realtime code-generated music. Max does what it does well, and shoehorning in interrupt level scheduling for scripting on top is out of scope for its remit.


Doing interrupt level scripting in it works just fine - lots of people have done it in C, C++, Scheme, and other extensions. I take it on stages and have produced music with it extensively. Scheme for Max is written using all the same C primitives from the Max SDK that the other Max sequencing options use and has been load and timing testing exhaustively.

I'm currently a PhD candidate in it, have previously used Csound, SuperCollider, Max, Pd, Common Music, and others, and have published/presented at conference on this topic. Of everything I've tried, I prefer working in Scheme in Max over other options. It is definitely practical and accurate. (Though in Scheme in Pd has soe nice features too!)


Can your external place objects and route cables around on the patch? That's the main thrust of my original comment, which is that JS scripting can help avoid having to patch lots of objects together in the GUI. Live scripting music is beyond the scope of my advice.

You specifically brought up "scheduling tasks". There is a JS task scheduler, but it comes with a caveat - the scheduled timing is accurate but the time of executing is not accurate because it runs in the UI thread. Hence my comment.

If you want to schedule tasks in Max accurately with code, you can either use Max, C extensions, or my extension.

yes, you can do patcher scripting from S4M as well as you can easily send messages to named objects, which is all you need in order to be able to do that. That is how max patching works - whether you do it in the GUI, JS, or messages to the patcher, the whole thing is just objects sending messages to other objects, and the patch is just a connected graph of references of instantiated objects. If you send message to a thispatcher object, you achieve the same thing under the hood as manipulating the GUI or going through JS. You can read about it if interested in the Max SDK documentation and in the Cipriani & Giri books on thispatching.


My company had 6 employees, I was the CTO and I can't imagine getting SOC2 certified without using Vanta - that was back in their early access/beta days.

I had no choice - we had so many security assessments spreadsheets sent by potential customers, that getting SOC2 saved us time in the long run.


I like the people at Vanta just fine but it really squicks me out to see people doing Vanta because it's the simplest way for them to clear this dumb hurdle --- that implies that they don't understand SOC2 and are just taking Vanta's word for it.

The problem is, Vanta will ask (suggest? come perilously close to demand?) you do a lot of engineering work that is absolutely not necessary for a SOC2 attestation. Worse still: whatever controls you attest in your SOC2, you're practically locked into. If Vanta has you set up some cloud detection capability, and it turns out as you mature your security organization that it wasn't necessary or even useful, you have a fight on your hands with your Type II auditor about why you stopped doing it.


It's all negotiable. I did audits and attestations at a bank, .. everything's negotiable.

> that implies that they don't understand SOC2

Good engineering and SOC2 compliance can be on similar but not identical paths. If you want SOC2, you're bending your engineering towards that particular standard. Getting SOC2 compliant because it's time, and you have the customers, is just a step, and not a reflection of whatever good engineering you've done. If you can defend it, you can probably keep some of your variances.

If you're a solopreneur and you've never been in/near an audit, and you're committed to a vendor like Vanta, I'd recommend hiring a consultant for even a few hours to give you independent coverage of industry norms and a little coaching on sticking points.


I wrote at length downthread about how much engineering absolutely should not be bending towards SOC2; it's the opposite.

https://news.ycombinator.com/item?id=48150405


I've been working with an organization that apparently won't give its developers reasonable access to dev cloud environments "because of SOC2." At least, that is the excuse they tell me.

Example: "I need access to EC2" isn't enough. I wind up with a role where I can launch instances, but not list them. I have to send several emails, have meetings, follow ups, sending links to AWS docs, etc. to get them to modify a custom IAM role. Then they still can't figure it out, so I am literally telling someone what to copy-and-paste into JSON to fix the issue. I completely understand more control in higher environments, but this crap adds up and costs weeks in lost productivity.


Oh, absolutely, security and compliance teams have for over a decade been exploiting SOC2 to exert undue control over engineering process.


Yep! It took a month of back-and-forth to do what should have taken less than a day in an environment with less friction. I'm totally frustrated by the project at this point.


I think we're in quite a bit of agreement.. sometimes the SOC2 review exposes gaps and you need to find a way to close them -- where do you look for critical path on that?

Also, SOC2 audits are sometimes coupled with more strenuous ones, so in the umbrella of audit season, you may have to demonstrate things, or records of things.


In my experience it was as simple as connecting to AWS and tagging resources in Terraform. I got it all done in around 3 weeks. So maybe yes, if somebody doesn’t know about SOC2 then Vanta might be getting in the way but it in my case it literally solved all my problems in a month or so


It has one - it’s been a part of the JDK for a while https://docs.oracle.com/en/java/javase/11/docs/api/jdk.https...


sun is typically not available anymore / deprecated even and not available in the JRE or it's early access, but fair point.


I get what you’re saying but this is actually a public api in HotSpot. It was provided in JEP 408: https://openjdk.org/jeps/408


so this is what it feels to be old...

but to clarify, this was about a year ago where I struggled to find an auto completion for HttpServer and when I searched it up jdk HttpServer was simply not in the results so I made assumptions that were wrong.


I don't remember the exact situation, but I think this relates to this:

Clojure core was sent a set of patches that were supposed to improve performance of immutable data structures but were provided without much consideration of the bigger picture or over optimized for a specific use case.

There's a Reddit thread which provides a bit more detail so excuse me if I got some of it wrong: https://www.reddit.com/r/Clojure/comments/a01hu2/the_current...

*Edit* - actually this a better summary: https://old.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey...


Dissatisfaction n. 3 is the essence of the problem: "Because Clojure is a language and other people's jobs and lives depend on it, the project no longer feels like someone's personal project which invites a more democratic contribution process". This is a common, and modern, feeling that the more users a certain thing has, the more the creators/maintainers have a duty to treat it as a "commons or public infrastructure" and give the users a vote on how the thing is to be managed and developed. This is, of course, utter horsesh*t.


Looks great, shame that due to annotation-based API it's gonna be a pain to use in Clojure.


One thing we're looking at right now is what it would take to support Clojure or Kotlin.


Fully declarative approach is the way to go for both IMHO. I'm more familiar with Kotlin than Kotlin. But its coroutines framework and structured concurrency are well aligned with something like this. Essentially you are doing is kind of a stateful form of structured concurrency where state is preserved in a DB and resilient against sub task failures, nodes dying, etc.

This reminds me of a product called restate. I talked to some people in that company a while ago. Their solution is built in Rust I think but they have clients for all sorts of platforms. Including Kotlin. Cool company and distributed workflow engines and agentic / long running workflows feel like a good match.

There are lots of other solutions in this space. I believe an ex Red Hat person is working on rebooting a workflow engine called Kogito based on something that orginally lived under their umbrella.

There's a long history of very enterprisy business process management stuff here. Lots of potential for overengineered solutions.

I once got sucked into a Spring Batch centric project and it was hopelessly overengineered for the requirements. Gave me a proper headache. Nothing was simple. Everything was littered in magic annotations causing all sorts of weird side effects. That's why I prefer declarative approaches with simple functions. Which is what the Kotlin syntax enables relative to Java. You can do the same technically in java but it quickly becomes an unreadable mess of function chaining.



It's doable but you need a lot, and I mean a lot of documentation proving that you are indeed an alien with extraordinary ability. Any press mentions of you and your company, articles, proof that you're working with known companies in the US and more evidence like that will increase your chance.

In fact I worked with Peter on obtaining an O1 while not having a degree, I was a CTO of a startup, moving from the UK.


Most of the time I have 4 or 6 buffers visible at once, including the REPL and files I’m editing - and that’s when I’m working on “one thing”, having packages like transpose frame or ace-window makes this type of workflow much easier


I could add at least 10 more to this list, just based on my personal experience


djaypro is what you want in this case - but you’ll also need a mixer/interface which supports DVS (like Numark Scratch).

There are all-in-one hardware options but from what I remember all of them come with their own control platters etc


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: