957 karma · joined November 7, 2011
I was the VP of Engineering at Intellinote
https://intellinote.net/
http://www.broadsoft.com/news/press-releases/broadsoft_acquires_intellinote
https://www.cisco.com/c/en/us/about/corporate-strategy-office/acquisitions/broadsoft.html
https://www.fatpick.com/
http://heyrod.com/
https://github.com/rodw- Neurotypical brain: https://www.amenclinics.com/wp-content/uploads/2019/11/healt...
- ADHD brain: https://www.amenclinics.com/wp-content/uploads/2019/11/add-a...
Articles:
- https://pubmed.ncbi.nlm.nih.gov/31014101/
- https://neurosciencenews.com/adhd-brain-markers-21931/
- https://www.amenclinics.com/conditions/adhd-add/ (source for the images above)
- etc.
This is a well documented result.
Or - hear me out - maybe severe ADHD, the kind that leads to diagnosis and treatment with stimulant medication at a very young age, is correlated with negative outcomes in general. You know, like a disability.
The number of people willing to believe - contrary to actual peer reviewed studies - that stimulant medication is harmful to people with ADHD, based on nothing more than a gut feeling, is astounding. People don't assume they can just intuit the proper treatment for other medical conditions, why do they think they can do that with mental health related issues?
Relative to the outcome for those same people had they remained untreated, or a "control group" of people with ADHD who were untreated, or just relative to neurotypical/non-ADHD people in general? Maybe ADHD has a negative impact even when treated.
> I believe those drugs are poison, especially when given to teenagers and younger.
You're making a dangerously uninformed claim. Actual, non-anecdotal, peer-reviewed studies strongly suggest the opposite of your observation. Untreated ADHD can have profoundly negative consequences.
Even with an incredibly spartan lifestyle, you'll have maintenance, insurance, inspection and registration fees on the van; health insurance; fuel costs (power when parked, gas when moving); phone service; gym membership (showers, bathroom); hygiene supplies/toiletries; laundry; clothing; household consumables; etc. $100/week seems like a stretch unless you're compromising on personal welfare and/or safety.
At some point you might as well just do away with the van and sleep in the office.
1. Control over the "distribution channel" is a major factor at least part of the time. The fields which are most notorious for low pay (e.g., books, music, photography) are the ones where the producers of the content are disconnected from the customers and instead sell via distributor. At least some of these middlemen are reaping the rewards of the low marginal cost (e.g. Spotify?), but I'm not sure if it applies to all of them (e.g., book publishers?). More to the point, software developers tend to have more direct control over the distribution channel (notably SaaS) and when they don't the distributor tends to takes a hefty chunk of the revenue (e.g. mobile app stores today, big-box retailers 20-30 years ago).
2. The "make it once, sell it infinitely" model doesn't really apply to newspapers (and maybe some of the other categories) in quite the same way. Yes, the marginal cost per view is essentially 0, so I can "sell" today's paper an infinite number of times. But the value of and interest in that content rapidly depreciates to 0 as soon as it becomes yesterday's news. The newspaper model isn't "write once, sell forever". You need to continue to "feed the beast". It's the ongoing production cost to continuously generate new content that dominates.
3. There may also be a correlation with "content" versus "services". Whether due to distribution mechanics or popular perception, it seems like application providers (e.g., Adobe, Microsoft) are able to enforce a pay-as-you-go subscription model but "pure" content providers are often trapped in a (lower-margin) advertising model because "information wants to be free" (or more to the point, is easily plagiarized by competitors or pirated by consumers). Digital or not, most of the "low pay" examples you cite fall into the content rather than service category.
It's a corollary to the Dunning-Kruger effect: don't assume programming is easy for _everyone_ just because you happen to be good at it.
I think "Chapter 1: The Tar Pit" of the venerable _Mythical Man Month_ (https://archive.org/details/MythicalManMonth) speaks to this in terms that are still applicable even after half a century. Here are some of the challenges Brooks describes:
1. "Most have emerged with running systems — few have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficulty — any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem"
2. "One must perform perfectly. [...] If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it."
3. "Other people set one's objectives, provide one's resources, and furnish one's information. One rarely controls the circumstances of his work, or even its goal. In management terms, one's authority is not sufficient for his responsibility."
4. "The dependence upon others has a particular case that is especially painful [...] He depends upon other people's programs. These are often maldesigned, poorly implemented, incompletely delivered, and poorly documented. So he must spend hours studying and fixing things that in an ideal world would be complete, available, and usable."
5. "[D]esigning grand concepts is fun; finding nitty little bugs is just work. With any creative activity comes dreary hours of tedious, painstaking labor [...] [D]ebugging has a linear convergence, or worse, where one somehow expects a quadratic sort of approach to the end. So testing drags on and on, the last difficult bugs taking more time to find than the first."
6. "The last woe, and sometimes the last straw, is that the product over which one has labored so long appears to be obsolete upon (or before) completion. Already colleagues and competitors are in hot pursuit of new and better ideas. Already the displacement of one's thought-child is not only conceived, but scheduled."
I think it's notable that even with five decades of global-scale investment in this field we haven't really _fixed_ any of these challenges. Our tools and practices have improved, certainly, but at best in proportion to the increasing demands of scope/scale/complexity. Context-aware, cloud-connected, toolchain-integrated IDEs with features like programmatic refactoring, REPL-like interactivity (or whatever other modern tooling you'd like to point to) are a giant step up in both usability and productivity compared to the batch processing of literal punch cards workflow that Brooks based his observations on. But I suspect those "woes" still resonate with most people involved with software development today. Projects still regularly fail to hit scope, schedule or budget. Small, obscure errors still sometimes lead to catastrophic failures. Reliability continues to be expensive to and is often fleeting.
The global system of systems that comprise the modern "technology infrastructure" is an ever-expanding, ever-shifting, frequently-unreliable and increasingly-critical house of cards. It's almost certainly the most sophisticated and complex artifact that humanity has ever produced. It's easy for those of us with significant interest, aptitude or experience with it to forget that. But this shit is _hard_. It's a wonder that it works at all.
Toward that end, while you can wave your hands around "how [little] work it takes to become [a programmer]", the fact is it takes a substantial amount of time and effort (and an moderately uncommon degree of aptitude) to become a competent one.
Are some software engineers over-compensated? Probably. But the difference between software engineering and medicine (for example) has less to do with the degree of specialized knowledge or level-of-effort required and more to do with credentialing and our ability to evaluate competence. You can take a 6-week "coding bootcamp" and call yourself a "programmer". You can't take a 6-week first-aid course and call yourself a "doctor". But they are both pretty far removed (in terms of experience and learning) from even a competent "journeyman" in their respective fields (say, a "principal engineer" and "resident", respectively - i.e., someone you could trust to take on a non-trivial level of critical responsibility with relatively little oversight).
To be fair the stakes are generally higher for a typical doctor than for even the most "senior" software engineers, but there's plenty of literally life-or-death software applications, both direct (e.g., medical diagnostics, 911 calling infrastructure, GPS, computer vision) and indirect (even something as mundane as network availability or the reliability of data search and retrieval). Not to mention the enormous number of systems for which failures in delivery or at run-time can have a substantial financial impact. I can't really speak to relative compensation: I imagine many doctors should probably be paid more and many programmers could probably be paid less (and the med-school/residency pipeline should almost certainly have a more sustainable work/life balance). But it's foolish to think that the upper-ish tier of software engineers (say, 40th+ percentile maybe?) doesn't represent a skilled, specialized, and therefore valuable labor force.
It's no surprise that there's a large number of highly compensated software engineers. There's a lot of extraordinarily valuable (from a financial perspective) work to be done and it takes substantial knowledge, experience, and aptitude to be able to do it well.
That said, I'm genuinely curious about how often and in what way that time-based information is actually used.
For example, I often see created_at and modified_at columns that are completely ignored by the actual business logic and application code that are only used (if ever) for ad hoc diagnostic purposes like reconstructing the sequence of events after some catastrophic error in the app logic screwed up the database. If run-away-logic-screwing-up-the-database is a legitimate cause for concern, that's probably reason enough to include that extra meta-data, but I can easily count on one hand the number of times that's come up in practice across my long career. I mean, I also include that sort of column often. And there are certainly entities for which those data are relevant for application logic and/or reporting purposes. But there are definitely cases in which those data are never used at all too.
If this `deleted_at` timestamp-as-boolean convention is popular enough in the Rails community to be universally known, is there some common use for knowing _when_ a record was logically deleted (outside of reconstructing of the database state after something goes wrong) that I'm missing?
I.e., is this something that's actually used in the typical business logic and application code, or is it primarily used for ad hoc debugging?
To be clear I'm not _doubting_ that such a use case exists, it's just that off the top of my head I can't think of commonly occurring one.
Assuming there's a justifiable need to apply the logical-delete idiom to the users table, what's the Rails-native, ActiveRecord-based approach to filtering out the logically deleted rows?
For what it's worth, I have built and managed systems where "delete/disable this thing in the future" is a valid use case, but I'm wondering whether/how often/how the date aspect of the Rails-style `deleted_at` is actually used. Does anyone ever care when the record was deleted, or is it just extra metadata that is occasionally used in an ad hoc way for debugging or diagnostics. If the typical rails app replaced `deleted_at` with boolean-valued column, would it actually matter?
You're not wrong, especially with the second part. I.e., deeply nested or convoluted dependencies between views can definitely make it awkward or painful to make adjustments near the root of the tree.
When I started this reply I was going to say "I hear you, but it's not an issue I run into very often". But that's not true. I've actually been burned by that moderately often, and have sometimes avoided or redesigned the root-level table change to avoid having to propagate all those changes to the rest of the dependency tree.
That said, in my experience (also mostly with postgres for this context) I feel like that's usually been more of a developer laziness issue (my own laziness that is), rather than an "ossified schema" issue. It's definitely a PITA when some simple change is going to break a dozen inter-connected views, but that's a coding issue not a deployment issue almost all of the time.
To be fair I don't really use matviews very often, but for true basic views I am guessing that the actual execution of the DDL to rebuild changed views is manageable in all but the most extreme cases. Even then there _should_ be a maintenance window of some sort available.
Thinking this thru a little bit, I believe the "anti-pattern" you're warning against isn't really views themselves but deeply nested/interconnected views (views that query other views, etc). I use views often (for this logical-delete type idiom for example) and I have rarely regretted it. I have often regretted creating complicated view-base dependency trees however, so I think I'm wholeheartedly in agreement on that point.
It seems to me that having a date-type column named `is_frobbed` is highly preferable to `frobbed_at` if your intent is for `IS NOT NULL` to mean frobbed.
Sure, it's a little weird to have boolean-sounding `is_frobbed` name for a date column, but the number of times that `frobbed_at IS [NOT] NULL` appears in the code is likely to dwarf the number of times you're inserting a date type into the `is_frobbed` column. I feel like there's always going to be someone (like me in this case) that's going to come across a `frobbed_at IS NOT NULL` case, notice that it's a date column and make the same flawed assumption I did. A similar thing will happen to the `is_frobbed` column too, but in that case trying to treat the date type as a boolean is going to make it obvious that you're not understanding the full context.
Frankly, if I was naming a column for this idiom and didn't have other constraints (like the Rails context), I would probably try to find a more exact and direct way to express it, if that's a little clunky. Maybe something like `frobbed_when_not_null`? But I don't love that. Honestly it may make more sense to have a actual boolean-valued `is_frobbed` column and an independent `frobbed_at` timestamp column that's populated by a trigger when the value of `is_frobbed` changes. I feel like "clunky but direct" beats out "elegant but misleading" in the long run, especially given the degree of "clunky" and "elegant" we're talking about here.
I don't expect to talk you out of it, and I'd fall in line with this in a Rails context too if that's the convention, but I think it's objectively poor design.
For what it's worth, if the `frobbed_at` convention usually intended to track the timestamp at which the frobbing happened, the good news is that my `AND frobbed_at <= NOW()` check would be unlikely to break anything in practice. Assuming that there's nothing weird going on with the timestamps, the frobbed_at dates will always be in the past anyway.
I mean I guess I can imagine a scenario where you want to know _when_ a record was logically deleted in addition to a flag that says is_deleted, but maybe that should be two different columns.
Or at the very least, `deleted_at` is a misleading name in that case. Interpreting `deleted_at` as "is deleted after but not before" is definitely a reasonable _enough_ interpretation. I agree it doesn't unambiguously mean that, but it's at best ambiguous enough to make for a bad column name if `IS NOT NULL` is the way you intend to check for a logical delete.
> you could to get the comparison flipped by accident, and if it's only in one place out of many that bug could go unnoticed for a while.
That's exactly why I proposed a database view as the proper solution to both whole `deleted_at IS NULL` "code leakage" issue. If you have a table that uses a logical-delete idiom that you intend to query from a bunch of different places in the code, a database view that filters out the logically deleted rows is a much more appropriate solution. It's a universally DRY solution. The single simple view covers all tech stacks, all services, etc., up to and including interacting with the database via some sort of REPL console.
If you need to add `deleted_at IS NULL` to, say, 90% of the queries against the `customer` table and you're afraid someone is going to forget to do that somewhere somehow, it seems pretty obvious kind of "extract common WHERE clause" refactoring is warranted. This is especially true in the actual "business meaning" context here. You are only going to be interested in the logically deleted rows in small number of specific circumstances. Having some way to extract away that detail from the 90% of the use cases where "logical deleted" is meant to be functionally equivalent to "actually deleted" seems extremely warranted. It's a perfect counter-example to overcome an aversion to using database views. I get that the `active_customer` abstraction is probably awkward to implement in a lot of application code contexts (depending on your ORM/DB-query framework I guess), but the database view is a simple and elegant way to address that really clearly defined need.
``` CREATE OR REPLACE VIEW active_customer AS SELECT * FROM customer WHERE deleted_at IS NULL OR deleted_at <= NOW() ; ```
There, I fixed it.
Just use `active_customer` instead of `customer ... deleted_at IS NULL`.
In fact, since the deleted_at column is a timestamp, the original "leakage" query:
``` SELECT * FROM customer WHERE id = @id AND deleted_at IS NULL; ```
is actually broken. A non-null `deleted_at` timestamp that's in the future implies the record hasn't been deleted yet, right?
I've often had junior devs assert that views are some kind of code smell, but these sorts of "canned query/filter that you want to apply very very often" seem like the perfect use case for a view to me. It's DRY, and the fact that your standard "query" is in the database" means you can change it more readily than trying to make sure you hit all the points it might be embedded in the application code.
> I feel like a lot of developers underutilize the capabilities of the massively advanced database engines they code against
Early-ish in the JDBC days a senior dev I was working with at the time (as a junior dev myself) made a pretty good case that "the database is part of the application" that's always stuck with me. Full database independence via software level abstractions is a pretty silly goal outside of library code. If you have a service that makes extensive use of the database, don't throw away the database features in the interest of some abstract "we could swap out oracle with mysql without changing anything" objective. If you want it to be generic, use the SQL standard, but don't be afraid to have a few db-specific bits in the app code if that's a subsystem you might replace once a decade or something.
I blame the DBA/Dev divide for a lot of this. A lot of the impedance between these layers is social/procedural. If you can change the DB as easily as the code, there's a lot less fear of using the right tool for the specific job.
I.e., if you want to use your personal device to access the organization's private network or resources, they are going to insist on having control over that device, or at least they are allowed to.
Or in this case I assume that CPS "owns" your son's account and probably has a terms-of-service-style document somewhere that makes GoGuardian or similar a condition of using that account.
If you don't want their software then you can't use "their" account on that computer. I don't love that policy, but it sure seems like something they are allowed to do.
Beyond the usual web-based suspects (some of which have been named elsewhere in this thread) there are also a number of other tab sharing "communities", including some relevant subreddits that might be the easiest way to spread the word if you're not comfortable uploading to a more directly for-profit service (not that Reddit isn't for-profit too, but guitar tabs certainly aren't their business model and you'd largely be linking to files stored elsewhere rather than uploading them directly).
But a lot of people seem to do what you did also. I suspect it's not super-effective as a distribution model, but if you dig a little it's not hard to find smaller/specialized tab collections on personal websites or general-purpose file hosting services like Google Drive/Dropbox or even at places like Github.
I don't think Google's `filetype:` operator respects guitar-tab-related extensions like `gpx` or `gp5` or `tab` or whatever but using the `inurl:` operator (or just including the tab-specific file extension) combined with the song title or artist name is a good way to find some of these less-centrally located tabs.
Also there are several massive collections available via torrent and on some of those more gray-hat-ish anonymous/one-off file-sharing services. Arguably these may have a more questionable provenance but I suspect the plurality if not the majority of the guitar tabs you'll find shared anywhere online could be traced back to old-school usenet or the first generation of tab-sharing websites that grew out those communities. Ultimate-Guitar for example self-reports as having "chords and tabs to over 1,100,000 songs", and likes to highlight their "official" (licensed) transcriptions (and to be fair they are nothing to sneeze at), but it's probably no coincidence that they don't seem to report the ratio of "official" to "community-provided" transcriptions.
EDIT: Just out of curiosity I checked the file-count reported at the bottom of UG's search page when filtered by file type, I see:
* 18,688 "official" tabs (AFAIK these are the only actually licensed transcriptions)
* 212,408 "Guitar Pro" (.gpx/.gp5/.gp4/.gp3) files; user-generated and many of which probably weren't originally uploaded to UG
* 1,115,129 plain-text transcriptions (801,597 "chords", 313,532 "tabs") that almost certainly date back to Usenet-era communities
The ~20K of licensed/official transcriptions are impressive (both individually and collectively) but represents less than 2% of the overall song catalog (and much less than 2% by file count).
Assuming the answer is "yes", I'm not sure if I follow the leap from "non-negative matrix factorization as a bank of note templates (from their spectrograms)" to "song recommendations".
Very loosely speaking my (not wholly uninformed) interpretation of the "note templates" bit is sorta analogous to DFFT analysis with frequency bins centered around the "regular" notes of the chromatic scale - i.e., the cells of the matrix represent signal strength for the frequencies that correspond to conventional western notes (e.g. integer-valued midi note numbers) or (in aggregated form) octave-independent pitch-classes rather than arbitrary frequencies (that might fall between two conventional notes). It's a very useful representation of the component frequencies that appear in conventional music but at the end of the day it's more or less "here are the notes (or pitch classes) active for this given beat".
That is, I can imagine the role this information - essentially the musical score itself, or at least the pitch-specific dimension of that score - could play in a song-recommendation engine, but I'm curious how/why that specific spectrogram-template-based representation is significant.
Are you suggesting that that specific representation could be applied to song recommendations in a way that similar polyphonic-pitch-per-beat information derived from some other algorithm (FFT analysis for a hypothetical example) could not?
Or maybe I've misinterpreted your comment entirely?
I mean, computational complexity aside it seems like at least hypothetically you could even just apply basic auto-correlation-style logic to detect the period of the combined wave much like you do in the monophonic case (assuming the chord is sustained for long enough to actually capture that full period, which of course it won't be in the general case). There's nothing magical about a neural-net or other deep-learning-style solution to this problem - at the end of the day that's just an approximation of a formula that could in theory be derived through more direct means anyway. And (as far as I know) there's no reason to believe the polyphonic case is fundamentally resistant to more traditional techniques.
And as implied by your comment, the problem is made easier (or at least less resource-intensive) in practice than it is in the abstract: we're mostly interested in audio that's comprised of actual notes from the chromatic scale (rather than a combination of arbitrary frequencies). There's only ~140 or so component frequencies we really need to consider in practice. (Not to mention the semi-predictable repetition/progression patterns you're likely to encounter in most conventional songs. That's inadequate by itself but certainly a good way to error correct, fill in gaps, resolve ambiguous cases, etc.)
But that said, it does seem like polyphonic pitch detection is a problem that responds really well to machine-learning techniques. In my experience, even a fairly simplistic ANN (e.g., no hidden layers, ~1k to ~10k weights depending upon how the inputs/outputs are modeled) - when seeded with a little bit of domain-specific knowledge - can very quickly learn to perform reliable polyphonic pitch detection under real-world conditions.
To be fair, I haven't quite put my money where my mouth is on this topic (yet): I develop software that includes this sort of functionality and the current production version uses more conventional (or at least direct) analysis rather than so called "deep learning" techniques for polyphonic pitch detection. There are pros and cons to either approach, but I can definitely see why some find the deep learning solution attractive. There's probably some degree of magical thinking involved (i.e., "AI will solve this pattern recognition problem that's too hard for me to work out from first principles"), but it also seems to work really well in this case.
For what it's worth I think you've got the right general idea, or at least (based on your brief description) I think I arrived at a solution that's based on some similar concepts and found it fairly effective (beyond the proof-of-concept phase). And as you noted there are related concepts discussed in some of the published academic research. I'd love to hear a little more about your approach if you're willing and able to share any more details. (Noting that at least part of my interest in that topic is selfish, of course.)
I apologize if this is obvious or well known to you, but for anyone not already familiar with it recognize that much like (and not wholly independent of) musical scales, chords are essentially defined by a predictable "formula".
E.g., every major chord is described by interval pattern 0-4-7: starting at any note, take the root, major-third (4 semi-tones above the root) and perfect-fifth (7 semi-tones above the root) and you have the major chord. For the root note C that yields C-E-G.
Rotate that pattern so that the root note is pitched above the major-third and perfect-fifth (e.g. something like 4-7-12) and you have an "inversion" of the major chord. For the root note C that's E-G-C (known as "C/E") or G-C-E (known as C/G).
Based on these interval patterns it's not hard to generate an exhaustive list of chord "families" (with members like "Major" or "Dom13Aug5" or whatever) - there are at most 4096 (=2**12) of these interval patterns in a single octave, and many of those are relatively uninteresting due to symmetry, degenerate cases or just plain dissonance. (To be fair many common chords span more than one octave.)
A given collection of notes (fret/string combos on a 6-string guitar for example) is usually going to map to some variation of one of those interval patterns, possibly with a stray interval added, dropped or repeated. (E.g., the typical X32010 fingering of C Major on guitar corresponds to C-E-G-C-E rather that "simply" C-E-G.)
So it might seem like mapping an arbitrary fingering to the corresponding chord name requires a lot of information, but it's just matching notes (or pitch classes) to a moderately small number of named interval patterns.
And it might seem like "F5addb5addb11addb13/A" is a ridiculously over-specified chord name, but that's a function of applying a set of conventional "modifiers" to a simpler/better-known/more-common chord. (In this case, `F5addb5addb11addb13` = `F5 + add(b5) + add(b11) + add(b13)`, i.e., F5 (F + C) with a diminished-5th (C), diminished-11th (B) and diminished-13th (C#) added.) You could argue that the pattern matching is trying too hard in this case, but if you're dedicated to assigning a "conventional" chord name to an arbitrary collection of notes, there's algorithmic way to do that.
Again, apologies if this is obvious to you (user Y_Y), I just thought I'd try to de-mystify it a bit for anyone to whom this seems like alchemy.
Music theory has a bunch of semi-arbitrary naming conventions that make it sound really complicated to the uninitiated, but in the abstract the chord names are basically just bit-masks that specify interval offsets from a given root note.
The "holy grail" of a universal AMT that works with any number of instruments of any type played concurrently isn't exactly an intractable problem to begin with, but if you constrain the problem in various ways (to specific instruments, to known tunings, etc.) you can definitely take advantage of a priori knowledge about the "timbre" of the instrument and the way in which the sound wave evolves over the duration of the note/notes to work-around what would otherwise be more ambiguous data. The octave/harmonics problem is one example of the kind of problem that is much easier to eliminate (relative to the abstract case) if you can make assumptions about the type of instrument that is generating the sound.
The overtones generated by the vibrations of a guitar string (for example) follow a fairly specific and distinctive pattern. If you dig a little bit into the physics/mechanics by which a given instrument generates sound there is a lot of tell-tale information to take advantage of.
The monophonic case (one note at a time) is fairly well solved at this point: there are decades old solutions in both the frequency domain (like FFT) and time domain (like auto-correlation and the dozens of refinements of that basic concept) that work quite well under less than ideal conditions and in near real-time. Even naive solution like just counting the number of zero-crossings in the audio signal to estimate the fundamental frequency works pretty well.
The polyphonic case (like chord detection) is trickier, especially depending on what you're looking for exactly. I.e., is it sufficient to say "that's a C Major chord" or are you looking for a specific inversion or even fingering? Does it need to happen in real-time based off a microphone or could you batch-process an audio file instead?
But there are both academic solutions and consumer-oriented tools that can do a reasonable job of it (again, depending on what you're looking for).
If you're looking for guitar-chord detection in particular, I'd recommend you take a look at Chordify (https://chordify.net/). I'm even the developer of a product that competes with (or at least overlaps with) Chordify, but frankly it pretty much does what it says on the tin (extracts chords from audio recordings with more than acceptable fidelity, especially if you're willing and able to refine that by ear using the automated transcription as a starting point).
I'm pretty sure Chorify's solution is based on "deep learning" (ANN) techniques, but others have noted in this thread that's not the only viable way to do it. I suspect some combination of increasing computational power and algorithmic refinements will eventually lead to a "direct analysis" approach that becomes as common/conventional for polyphonic pitch detection as FFT and AC are for the monophonic case. There are already a number of fairly effective techniques depending on the constraints you want to put on the problem.
Between the constrained syntax, literal keywords, standard APIs and common coding conventions it seems like even independently-authored source code listings will be superficially similar. Certainly the basic/naive markov-chain-style logic that works really well for detecting even small examples of plagiarism in natural language content isn't going to as effective on `public static void main(String[] args)` or whatever.
Obviously there are strategies that could distinguish superficial/boilerplate stuff from truly duplicated code, but between the volume of actual (and often legitimate) duplication on the internet and the (maybe?) low ROI for duplicate content penalties for code relative to other value metrics/signals, maybe this just isn't terribly important as a quality factor?
Searching just now I do see some other sources making a similar claim, so maybe I'm just out of the loop. But in my cursory scan I haven't found much detail or real evidence beyond "google says they matter" either. I mean, that's not why those internal links were created in the first place, but it sure would be nice to get a ranking boost out of them too. I wonder what I'm doing wrong :)
I was a little surprised how much DOOM I listened to on Spotify in 2020. I two tracks from MM...FOOD in my top 20 (the other was Guinnesses (feat. Angelika & 4ize) - https://www.youtube.com/watch?v=5MW4d-Cp19E), and some collaborations (J Dilla, Avalanches/Danny Brown) farther down the list.
This is sad. I didn't even know his real name (Daniel Dumile), nor that he was actually British (mostly raised in NY). Weird to mourn the passing of someone you've never met and barely knew anything about, but he was only 49. Like a friend of mine once said in response to another artist's death: "something that brought me joy has disappeared from this world." He will be missed.
At first I had stuff "Waitress in the Sky" or "Tommy Gets His Tonsils Out" or "Alex Chilton" or whatever in mind, but now that I think about it there's a dark undercurrent to plenty of the songs in the core Replacements canon: "Hold my Life", "Unsatisified", "I Will Dare", "Bastards of Young", "I'll Be You", etc. - not to mention of a handful of slow tempo tracks with obviously dark themes.
I don't normally associate the Replacements with mopey music but in retrospect I'm not sure why. It's kinda all over the place, under a very thin veneer of drunken cynicism.
This fascinates me. I'd guesstimate that roughly 60% of the recommendations I get from YouTube are for videos I've already seen. (To be fair I "watch" a decent amount of music on YouTube, so maybe I'm disproportionately likely to rewatch videos I've seen before.) Another 30% is content based on misinterpretation of my political beliefs, like "you watched a critical analysis of a Prager U video, maybe you'd like these 6 Trump-stanning videos from Newsmax".
The political thing seems like an obvious blindspot in the YouTube recommendation algorithm to me. Going all the way back to 2015 YouTube seems unable to distinguish between "critical of establishment Democrats" and "intellectual-dark-web / pro-Trump" interests. I'll watch one lefty "breadtube" video that's critical of someone like Biden or Pelosi or complimentary to someone like AOC or Sanders and get Newsmax/OAN/Fox-and-Friends video recommendations for a week.
More generally it seems to me that YouTube's recommendation engine is far too volatile and heavily influenced by recently watched content. A one-off, slightly out-of-character view will noticeably taint my recommendations for a week or two.
In contrast I'd say Spotify, Google Music (before it was folded into YouTube), Netflix, Twitter, Amazon Prime, or even Pocket-via-Firefox does OK - not great but acceptably well - so I don't think I'm especially inscrutable. I'm curious about your experience with this. I have moderately broad interests, I feel like it shouldn't be hard to come up with something I would find interesting but it virtually never seems to happen organically on YouTube.
I've always just assumed they were optimizing for something other than things I would consciously find interesting or engaging. For example I'm guessing that triggering "outrage" is probably a good way to drive engagement (comments, shares, etc.). I don't really do either of those things regardless but I'm pretty sure that strategy works in general.
Do you find that YouTube frequently recommends novel content you enjoy? Is that even what they (or your company) is trying to do?
IMO this is a big red flag that something is wrong with both the technical and non-technical culture. Technical management isn't happening, at least not effectively, and non-technical management is getting too far into the weeds on technical details of production issues.