The Joys Of Programming

*Legion* wrote:
Quintin_Stone wrote:

We're doing Angular training right now.

Chapter 1: Use React instead

Chapter 2: Use Vue instead

Citizen86 wrote:
*Legion* wrote:
Quintin_Stone wrote:

We're doing Angular training right now.

Chapter 1: Use React instead

Chapter 2: Use Vue instead

Also acceptable.

Citizen86 wrote:
*Legion* wrote:
Quintin_Stone wrote:

We're doing Angular training right now.

Chapter 1: Use React instead

Chapter 2: Use Vue instead

Chapter 3: Something new will be out in 6 months, just wait

Citizen86 wrote:
*Legion* wrote:
Quintin_Stone wrote:

We're doing Angular training right now.

Chapter 1: Use React instead

Chapter 2: Use Vue instead

When I first tried angular I couldn't get some tutorial code to work, and eventually discovered the reason: the API I was passing a callback to behaved differently depending on what the callback's parameters were named.

I bounced hard after that, it felt like less of a framework and more of a career choice. I then tried Vue and lived happily ever after.

fenomas wrote:

When I first tried angular I couldn't get some tutorial code to work, and eventually discovered the reason: the API I was passing a callback to behaved differently depending on what the callback's parameters were named.

I bounced hard after that, it felt like less of a framework and more of a career choice. I then tried Vue and lived happily ever after.

Isn't that Angular's dependency injection? I agree it's rather nuts, but that's what it is.

Typehinting is a wonderful thing when paired with dependency injection.

Citizen86 wrote:

Isn't that Angular's dependency injection? I agree it's rather nuts, but that's what it is.

Typehinting is a wonderful thing when paired with dependency injection.

Some angular folks explained it to me but I forget the details - I think the idea was that Angular has two ways of doing DI and this was the one that isn't recommended and most people turn off, or something.

I mean I'm sure it's there for a good reason, but my takeaway was that angular was not the friendly idiomatic front-end framework I was looking for, that would bind a given state to a given UI and otherwise stay out of your way.

Quintin_Stone wrote:
Citizen86 wrote:

lol, HTML forms aren't going anywhere... unfortunately....

Yeah, I was just saying this is literally what I was doing in 1996. Probably 1995 since I was doing it part-time during college.

The web. The web never changes.

Citizen86 wrote:
Citizen86 wrote:
*Legion* wrote:
Quintin_Stone wrote:

We're doing Angular training right now.

Chapter 1: Use React instead

Chapter 2: Use Vue instead

Chapter 3: Something new will be out in 6 months, just wait

Chapter 4: Cry when you realize that your project still has to support IE 8

Citizen86 wrote:

Typehinting is a wonderful thing when paired with dependency injection.

DI in Angular would be 1000% times better if JS/ES had a concept of Interfaces.

Alternatively, you can use something like ng-annotate to hand-wave away 99% of the DI shenanigans.

fenomas wrote:

I mean I'm sure it's there for a good reason, but my takeaway was that angular was not the friendly idiomatic front-end framework I was looking for, that would bind a given state to a given UI and otherwise stay out of your way.

It'll do that, but it's definitely opinionated about how you should do things. So there's a learning curve but it's not horrible once you wrap your head around it. Also understanding how to structure your project into components makes life a lot easier.

shoptroll wrote:

Chapter 4: Cry when you realize that your project still has to support IE 8

Oh man, if I had a nickel for every tear I shed during Chapter 4...

WRT frontend frameworks I am really impressed with ractive. Very lightweight, plays nicely with other frameworks/libraries, not a very steep learning curve and not especially opinionated about your application. I've been very impressed with it so far.

shoptroll wrote:

It'll do that, but it's definitely opinionated about how you should do things. So there's a learning curve but it's not horrible once you wrap your head around it. Also understanding how to structure your project into components makes life a lot easier.

Yeah, I'm sure it's great but it demands to be grokked. The nice thing about Vue is that at the moment I'm using it without knowing the framework - I mean I learned it when I first set up the UI of my current project, but that was months ago and I've forgotten nearly everything. But when I need to add or change UI stuff, Vue is so idiomatic that I can just glance at my existing code and guess what to do, and it usually turns out to be right.

I imagine there's a ceiling on what Vue can handle but below that it's really nice.

DanB wrote:

WRT frontend frameworks I am really impressed with ractive. Very lightweight, plays nicely with other frameworks/libraries, not a very steep learning curve and not especially opinionated about your application. I've been very impressed with it so far.

For whippituppitude ractive can't be beat. I used it when I was prototyping and really dug it (plus bonus points for the name).

Just found this listicle while searching for other stuff:

15 Free Games to Level Up Your Coding Skills
https://skillcrush.com/2017/04/03/fr...

There's some really neat stuff out there.

Hey, shot in the dark, but is anyone here familiar with programmatic audio processing?

Specifically I'm looking at a reference that reads:

Cheaper reverb [compared to using a Convolver] can be created using delay lines, all-pass and low-pass filters, to achieve a very convincing effect.

Does anyone know how that might be done in practice? All I can find online is academic sources that talk about the equations involved, I can't find anything talking about implementation.

fenomas wrote:

Hey, shot in the dark, but is anyone here familiar with programmatic audio processing?

Specifically I'm looking at a reference that reads:

Cheaper reverb [compared to using a Convolver] can be created using delay lines, all-pass and low-pass filters, to achieve a very convincing effect.

Does anyone know how that might be done in practice? All I can find online is academic sources that talk about the equations involved, I can't find anything talking about implementation.

At what level of detail do you need an answer? I know enough about what that sentence means that if I re-learnt enough C I could probably bolt together a very bad reverb implementation.

There are many open source implementations of reverb

Consider just using a zero latency reverb provided by
http://www.nongnu.org/freeverb3/

This guy has a series of article on implementing delay and filter based algorithmic reverbs
https://christianfloisand.wordpress....

Or you could just check out the implementation in Audacity's gverb or other reverb plugins
http://manual.audacityteam.org/man/r...
http://wiki.audacityteam.org/wiki/GVerb

I believe audacity implement a version of freeverb and that implementation is discussed at
https://ccrma.stanford.edu/~jos/pasp...

fenomas wrote:

Hey, shot in the dark, but is anyone here familiar with programmatic audio processing?

Specifically I'm looking at a reference that reads:

Cheaper reverb [compared to using a Convolver] can be created using delay lines, all-pass and low-pass filters, to achieve a very convincing effect.

Does anyone know how that might be done in practice? All I can find online is academic sources that talk about the equations involved, I can't find anything talking about implementation.

If the question is how exactly you implement each audio filter, I can't really help. I'm not an audio programmer, dsp programming scares me. The way it tends to work is that each filter is implemented as a node which can be connected, to other nodes. How that composition is done is going to be language (or your UI tooling) dependent.

If you want a quick idea of what those filters do then I tend to think of them as:
Delay Lines Filter: Takes an Audio Source, returns the Audio Source with an time offset. (Gives you the delay in the reverb)
All-Pass Filter: Takes an Audio Source, returns the Audio Source where each frequency gets a different phase shift (Gives you the wobble in the reverb)
Low Pass Filter: Takes an Audio Source, returns the Audio Source with the high frequency signal removed (Makes the reverb more bass).

Each filter can pass it's outputted source as input source to the next filter, if you play with the ordering, repeat the filters with different parameters, then you'll eventually get something that sounds like what you want.

Ooh, thanks for the replies chaps. In my case I'm working with WebAudio, so the nodes and filters are existing black boxes and the question is how to combine them. Web audio already has a ConvolverNode that does reverb quite well if you supply a suitable impulse, but it's very CPU intensive, which led me to the web audio source I quoted.

So my naive approach was to feed my input into ~10 parallel chains of (gain > delay > all-pass > low-pass), and then feed all those chains ((plus the dry input) to my output. The thinking being that each chain simulated a different delayed, muted, out-of-phase echo. But various tweakings of settings didn't yield anything particularly reverb-like, so probably I'm miles off.

Sorry for the lack of detail before, hope that's clearer. FWIW the tools at hand are specifically filter nodes and delay nodes.

Hmm. At first glance, DanB's second link may well be where I need to start. There's a lot of unfamiliar terms there I haven't sussed yet though.

The last link I provided has lots of the theory stuff on linking the nodes

If it is super mystifying I can ask a friend who teaches this stuff where to find good resources on implementing it

DanB wrote:

The last link I provided has lots of the theory stuff on linking the nodes

If it is super mystifying I can ask a friend who teaches this stuff where to find good resources on implementing it

Yeah, I see what you mean. I'm afraid that link puts me in a sweet spot, where I now think I understand what the diagram is specifying, but when I code it up the results sound like they're in the right ballpark but clearly not quite right. So I'm misinterpreting something, but it's hard to guess what.

Do you have any idea what units the delay numbers on the left-side comb filters would be? (1557, 1617, etc.) I'm guessing they're numbers of samples, since nothing else seems to make sense, but I can't find anything in the link.

Likewise for the AP nodes on the right - the allpass filters I'm working with only have two parameters, frequency and gain, which is what the numbers in the diagram very much look like so I'm just guessing they line up. But the link's explanation of that part gets pretty hairy so that guess could be wildly off.

No worries if you don't know of course, but if the diagrams are clear to you any help would be super!

fenomas wrote:

Do you have any idea what units the delay numbers on the left-side comb filters would be? (1557, 1617, etc.) I'm guessing they're numbers of samples, since nothing else seems to make sense, but I can't find anything in the link.

Following through a link took me to

https://ccrma.stanford.edu/~jos/pasp...

Where that large number is N. Which certainly suggests something like sample number but it is not clear to be either.

With regards things not quite sounding right, from what I've read the basic Schroeder and Moorer algorithms for reverb sound tinny or metallic and not very right. I'll send my friend a message.

Lackrin wrote:

Throw my 2 cents into this. As a C# developer working in the corporate world for 13 years, i think you should look into C# and maybe learning a bit of an accounting system, like SAP, PeopleSoft or Microsoft AX.

Thanks for your perspective. I agree with you that, realistically, I'll likely be too old to be considered for jobs at start-ups and my expertise in accounting/finance is likely to be considered more of an asset in more traditional corporate organizations. I'll do some reading on the .NET stack (I've also been exploring MEAN since I have more experience with javascript as opposed to C#).

So much to learn, so little time....

Late to the party. With your background, your biggest value will be automating the stuff the finance people currently rely on Excel for. You need to learn any web/database combo. C# is a perfectly good route, and has a very easy "magically delicious" tech stack that Just Works for doing simple, internal apps, and has excellent support for working with Excel. Visual Studio even includes SQL Server Express for free.

A staggering percentage of the job of your average big business finance person is to gather some set of inputs over a period of time, insert them into Excel, do things on the data, and then craft a summary sheet and some kind of PowerPoint presentation with their results. The scut work portion of this can be automated with very light development knowledge.

1. Write an ASP page that accepts some values and stores them to a database.
2. Write another page that displays the contents of the database in a table.
3. Write another page that displays the contents in a graph (myriad third-party tools exist for this. Tableau, DevExpress, Telerik were all popular options when I wrote about 200 of these types of apps several years ago).

You now know enough to automate 50% of the job of your average PM. Continuing.

1. Add the ability to edit database contents from your page, rather than just inserting new rows.
2. Add the ability to export the contents to Excel.
3. Add the ability to import the contents of an Excel file which matches the column headers of the one you just export.

You now know enough to relieve the finance people of all that tiresome gathering of information. They can instruct people to get their data in, export the stuff to Excel, do their work, and then upload the massaged information back to the database. Continuing.

1. Add any authentication system. Doesn't matter which, you can roll your own or use LDAP or whatever. No two companies will ever use the same thing; you're just learning the concept of tracking user identities and permissions.
2. Add user roles (can insert, can edit, can delete, can export, can import).
3. Add some pre-defined export queries, so different people can export different stuff.

You can now automate away a sizable portion of the daily tasks of the worker bees at any large company. With this level of knowledge, you can be useful at anywhere that has several thousand employees, and "grow my org" middle management types will dread when you get assigned to help them. Continuing.

1. Add some email alerts. User X hasn't entered new rows by Thursday? Email a warning to them and an administrator.
2. Add automatic report generation. Build various graphs directly to static HTML pages that are automatically stored on the server, and automatically send them via email.

The average PM now has nothing to do other than keep calling for those "get in-sync" meetings. You can put all their project tracking and status reporting into a system just like the one you've already built.

I'll stop there. Nothing here is remotely complicated if you just patiently google your way through it, and you don't even need to land a software development job to do it. You just land any finance job anywhere with thousands of employees, and start automating the stuff your group does. You can run everything off of a computer sitting in the corner of your cube until it gets popular enough that you can justify running it on something real. In no time at all, you'll be "shadow IT" for the finance department, and you're off to the races.

And spend very little time worrying about best practices for anything. Just build a thing that works when used the way you intend it to be used. You'll learn plenty of lessons on later projects. That's when you start googling for a currently accepted according-to-Hoyle way to handle security or whatever.

Mr Crinkle wrote:

And spend very little time worrying about best practices for anything. Just build a thing that works when used the way you intend it to be used. You'll learn plenty of lessons on later projects. That's when you start googling for a currently accepted according-to-Hoyle way to handle security or whatever.

Who ever has to maintain that code after he leaves will really appreciate this advice....

DanB wrote:
fenomas wrote:

Do you have any idea what units the delay numbers on the left-side comb filters would be? (1557, 1617, etc.) I'm guessing they're numbers of samples, since nothing else seems to make sense, but I can't find anything in the link.

Following through a link took me to

https://ccrma.stanford.edu/~jos/pasp...

Where that large number is N. Which certainly suggests something like sample number but it is not clear to be either.

With regards things not quite sounding right, from what I've read the basic Schroeder and Moorer algorithms for reverb sound tinny or metallic and not very right. I'll send my friend a message.

update! My friend says the following:

"The N values are the lengths of the delay in the comb filters (which are essentially a long string of N zeros with a coefficient at the end that is tuned according to the reverb time. Across the comb filters N is usually a prime number, so that the frequency responses of the comb filters don't coincide."

And

" Zolzer's DAFx book is a very good introduction to implementation of lots of audio processing"

Mr Crinkle wrote:

[awesome stuff]

Thanks for posting this. I feel like my career will end up somewhere in this direction. It's nice to see it laid out like that.

PWAlessi wrote:
Mr Crinkle wrote:

And spend very little time worrying about best practices for anything. Just build a thing that works when used the way you intend it to be used. You'll learn plenty of lessons on later projects. That's when you start googling for a currently accepted according-to-Hoyle way to handle security or whatever.

Who ever has to maintain that code after he leaves will really appreciate this advice....

Job Security: The Next Generation.

NakedHavoc wrote:
PWAlessi wrote:
Mr Crinkle wrote:

And spend very little time worrying about best practices for anything. Just build a thing that works when used the way you intend it to be used. You'll learn plenty of lessons on later projects. That's when you start googling for a currently accepted according-to-Hoyle way to handle security or whatever.

Who ever has to maintain that code after he leaves will really appreciate this advice....

Job Security: The Next Generation.

I'm glad my predecessors were pretty much hacks. Makes me look like a hero when I can triple the speed of anything they worked on. It got me a promotion a while ago.

Mr Crinkle wrote:

Insanely helpful post

Wow - I can't thank you enough for typing all of that out. That was INCREDIBLY helpful.

I've been having a lot of difficulty deciding what types of development skills I should be focusing on in light of my background and you basically just outlined an entire complete project for me. I now know exactly what I'll be working on in the evenings for the next couple of months or so.

You mentioned that you've written similar apps 200-or so times. Do you mind me asking what type of organization you work for?

PWAlessi wrote:
Mr Crinkle wrote:

And spend very little time worrying about best practices for anything. Just build a thing that works when used the way you intend it to be used. You'll learn plenty of lessons on later projects. That's when you start googling for a currently accepted according-to-Hoyle way to handle security or whatever.

Who ever has to maintain that code after he leaves will really appreciate this advice....

He's doing a learn-to-code project prior to working anywhere. I would hope no one is going to maintain it. I saw two common problems when trying to encourage technical people to learn to code at work:

1. They didn't know what to write (I hope my above post provides that).
2. They got bogged down in googling the "right" way to do something. You have no experience with which to make an informed decision when starting out. Just build. Building well comes later. And if you become a reasonably good developer, you'll always look back at stuff from over a year ago and go "jeez, what the hell was I thinking, I would do that so much better now."

Pinkerton wrote:

You mentioned that you've written similar apps 200-or so times. Do you mind me asking what type of organization you work for?

I wrote the vast majority when I was working at a large healthcare organization. But again, all giant organizations are the same in this respect. They all do a ton of sh*t in Excel and PowerPoint, and people who can move the bulk of those workflows onto the web will always be useful.

Mr Crinkle wrote:

And if you become a reasonably good developer, you'll always look back at stuff from over a year ago and go "jeez, what the hell was I thinking, I would do that so much better now."

I've routinely seen stuff I wrote a few weeks ago at work and immediately want to hop in the DeLorean and punch past-Shoptroll in the face for it. A year is nothing.

DanB wrote:

update! My friend says the following:

"The N values are the lengths of the delay in the comb filters (which are essentially a long string of N zeros with a coefficient at the end that is tuned according to the reverb time. Across the comb filters N is usually a prime number, so that the frequency responses of the comb filters don't coincide."

And

" Zolzer's DAFx book is a very good introduction to implementation of lots of audio processing"

Hmm. Thanks very much for following up! Though it doesn't technically answer our question. I guess the implication is that the delays should be coprime so the units aren't necessarily fixed, which probably just means that the thing I'm misinterpreting was somewhere else.

I guess there's no easy answer here, so I'd probably better not go any farther down this rabbit hole lest I start reading DSP textbooks.