Breakpoints don't work with included scripts

[Lindon]

@clevername27 well if you make a list with examples (or better still snippets) we can all have a look at them...

[clevername27]

@Lindon Thanks for your response - didn't mean to ghost you. The breakpoints thing is a big one for me. Lack of documentation is another. Most of the issues I experience are in the editor, and unexpected limitations of the API (like the XML file reader only supporting a subset of XML files).

Overall, there just doesn't seem to be active development on the project any more—which I'm not complaining about, as I didn't pay anything to use it. I've contributed a bunch of stuff to the project…over a thousand lines of code, and lots documentation, so I'm not being hypocritical. It's just frustrating—I'd much rather pay @Christoph-Hart a few hundred bucks (I've even offered) and have a commercial-quality product, but that's certainly not something I expect from him—I'm simply grateful for the work he's done.

I'm not sure what use it is for for me to post a list of problems I've had with the software. Some are undoubtably things I'm doing wrong, but most of them obviously are not, including some mentioned on the forum by others (such as yours here), or replies to my own posts. I want to be constructive here, as so many people (such as yourself) have helped me. And pursuant to you request, I did write up a formal list of issues, styled as an industry-style report. It's two pages, single-spaced, and covers a lot of ground. But I've stopped short of posting it.

The community really isn't in a position to fix these issues, so I'm not sure what value there is in pointing these issues out. Plus, we seem to be aware of them. And Chris doesn't need me to point this stuff out.

I've gotten somewhat familiar with the HISE code, and made a few customizations for myself, but…and I say this with all due respect…it's really not (in my humble opinion) written in way that invites collaboration. In terms of architecture, it's more than solid. But comments are non-existent, and a lot of stuff that (ideally) should be dynamic is static (especially the editor), and spread across multiple files. He's done the hard parts right, but stuff like polymorphism is strangely absent—even to the point where colors have different names, depending whether you're in an LAF function or not.

My own contributions have largely been ignored—which is fine, but I'm not really motivated to make more. I spent almost a week, full-time, on one of them. I've got one more large contribution to post soon, but I'm calling it quits after that.

Overall (not that anyone asked, but for what it's worth) I feel that HISE has far too features, instead of a focus on getting the necessary ones to work. The amount of stuff available in the editor rivals some commercial IDEs, but I don't see the point when simply scrolling doesn't work (cutting out after a few scrolls) in the interface designer, or the API website has links that go to pages that don't exist.

Faust is great, but it's seems a little odd to add when basic stuff is problematic. To put it another way, the problem with HISE isn't that Faust wasn't possible. I realize the work was done by someone else, and that's awesome—but project management sometimes involves the hard choices of saying no.

As an audio scientist, I appreciate @Christoph-Hart;s Javascript for signal processing—it's brilliant work—in terms of functionality, performance and academic merit. It puts everything else to shame. Some of the HISE architecture is serious engineering, and more than anything, Chris understands, at a deep level, what's required for high-performance, efficient development—and he hasn't shied away from the difficult places necessary to do this. He has my respect.

The ScriptNode environment is excellent, as well. It's no small feat to recreate parts of Max/PD, especially with the performance engineering he's done to make it efficient. I've written a compiler—it's insanely complex, let alone writing an optimized one as Chris has done.

His documentation on the architecture is excellent. While I like and use Kontact (and full disclosure, am an endorsed artist), as developers, we sure as hell don't get an explanation of what's going on under the hood, let alone the ability to inspect it ourselves. But Kontact works. Although (and with great appreciate for NI's support), it's nowhere near as good as HISE—except of course in terms of documentation and reliability. (And don't get me started on the licensing.)

HISE is, of course, a commercial product. As someone who works a lot in the commercial audio product industry, I think it would make a great commercial product if was fully supported as such. (And I've offered to help make that happen. But instead, we may simply roll own, similar environment—but I'd rather not. We won't do it as well as him.)

The best thing I can say, in terms of reliability, is that the executables are pretty solid. And as someone who's done a lot of commercial projects, that's no small feat of engineering in the design and execution of HISE. But how long will that last? When I look at the commits to GIT, there's barely any activity. Just about everything is from months or years ago.

HISE may not be everything I want it to be, and I realize that is solely my problem. Other people obviously use it for commercial products, and are quite happy with it. So it's' really my own problem. So, in a long-winded answer to question, because I recognize this as my own problem, and that users are not really in a position to fix issues, I may complain here and there about things, but I probably shouldn't.

[d.healey]

Overall, there just doesn't seem to be active development on the project any more

Every year around this time Christoph goes into HISE hibernation as he is working on his theatre projects. Usual development pace will resume once that work is completed.

But comments are non-existent,

I used to see this as a problem too (being an ex-comment zealot) but a few years ago my approach to commenting changed and now I very rarely need comments in my code. The main reason I use them now is to highlight individual sections of my code. Because comments are coloured green I can see them quickly when scanning through the code and it makes a little quicker for me to jump around. But I don't really need them for the information side of things because that is embodied in the code itself.

This video kind of sums up my approach:
https://www.youtube.com/watch?v=Bf7vDBBOBUA

[clevername27]

@d-healey The first thing I'll say is what everyone knows—without your consistent contributions, there would be no HISE, period. It's why I continue subscribe to your Patreon, even though I'm past the point of needing it. The point is we need you!

In terms of comments, as a former university lecturer (pre-COVID-19), I respectfully disagree. Likewise, on the commercial projects I manage, code without comments go right back to the programmer. I mean HISE literally has single-letter variable names. It's possible to write self-documenting code (e.g., see my tutorials), but comments are also (in my opinion) necessary (again I'd point to my tutorials).

EDIT: As always, thank you for your response, and sharing your perspective.

[Lindon]

@clevername27 said in Breakpoints don't work with included scripts:

I did write up a formal list of issues, styled as an industry-style report. It's two pages, single-spaced, and covers a lot of ground. But I've stopped short of posting it.

So if you look back thru the forum you may discover (agreed it may be difficult to find by accident) there was a post about the outstanding issues we all had at the time - this was a list that a good solid proportion of which Christoph took on board and fixed. So I encourage you, especially as you have already created it, to post a list of your issues, we all may well be able to add to it.

As you say you have been PM on commercial projects and I'm sure you will acknowledge the importance of bug-reporting in the path to a viable product release/update, so your contribution would be valuable.

[Christoph Hart]

It's just frustrating—I'd much rather pay @Christoph-Hart a few hundred bucks

A few hundred bucks will not be enough to fix everything that's wrong with HISE :)

And pursuant to you request, I did write up a formal list of issues, styled as an industry-style report. It's two pages, single-spaced, and covers a lot of ground

As Lindon said, please post it. I can't guarantee to address those right away but it's still good to have them listed so I can chew through them when I got some time.

My own contributions have largely been ignored

Are you talking about pull requests? I didn't see any from you, also you need to sign the CLA here before I can merge them, but there are a few people (Greg, David) which have committed quite a few quality of life improvements to the HISE codebase.

Every year around this time Christoph goes into HISE hibernation as he is working on his theatre projects. Usual development pace will resume once that work is completed.

And now I'm back!!

[d.healey]

@Christoph-Hart said in Breakpoints don't work with included scripts:

And now I'm back!!

Hope your theatre stuff went well!

[ustk]

@Christoph-Hart said in Breakpoints don't work with included scripts:

And pursuant to you request, I did write up a formal list of issues, styled as an industry-style report. It's two pages, single-spaced, and covers a lot of ground

As Lindon said, please post it. I can't guarantee to address those right away but it's still good to have them listed so I can chew through them when I got some time.

I'd say that after reporting a list of issues in the forum so they can be verified by all, I strongly suggest to report them to Github, so they're all in one place and won't end up to be buried after a few days/weeks. Speaking of which, I have a few issues coming up

[d.healey]

@Christoph-Hart @ustk I think now is a good time for Christoph to make issue github templates for bug reports and feature requests. :D

[clevername27]

@Lindon Thank you for your suggestion; I will do so, and undoubtably some will simply be things I do not properly understand. Thank you for all your contributions on the forum.

[clevername27]

@Christoph-Hart Thank you for your reply. Please know that I don't feel you have an obligation to "fix" anything—you have published at the source code. If I really don't like something, I can fix it. I likewise feel that you're probably well-aware of everything that needs to be done, and having someone document it excruciating detail may not be helpful as I think. But as I've been encouraged, I will do so.