Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: DSP LOAD/SAVE  (Read 5915 times)


  • Galactic Citizen
  • ****
  • Posts: 307
« on: August 27, 2014, 06:27:47 pm »

Re: New Features in MC20
Reply #2 on: August 11, 2014, 04:37:08 pm
Some more:
NEW: Added Play > Add (after current album) to play files after the current album ends.
NEW: Theater View has an option for whether file deletion is offered.
NEW: DSP presets can be loaded per file by setting the DSP field (the list is from Load/Save on DSP Studio).
NEW: Added 'Date First Rated' field.
NEW: Added a Load/Save button to DSP Studio.
How smart is this?  Does it just blindly assume anything checked starting at Equalizer (or a DSP in its position), or is it smart about things like convolution, room correction and the like?

As an example, I use convolution all the time for the room and if it is blindly saved for any one song, you might end up with double convolution, or none.  So could we have some more details about the inner workings of this?  It would be pretty annoying to have to undo your on-always options every time you want to save something unique to a song.

And, what of VST plugins in the DSP list?  Are they honored or ignored?

Details please?

It would be really nice if the items selected for Save could somehow be unique and separate for static always-on settings.



  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42079
  • Shoes gone again!
« Reply #1 on: August 27, 2014, 06:58:36 pm »

Save saves a snapshot of all DSP settings.  Load loads the settings. 

I'm not sure if VST effects are included.  Maybe not.
Matt Ashland, JRiver Media Center


  • Galactic Citizen
  • ****
  • Posts: 307
« Reply #2 on: August 27, 2014, 08:56:46 pm »

So every track you want unique processing for, you'll need to uncheck your global dsp's off, set the ones you really want on and to the correct parameters, and then turn off the SAVE options and re-establish your globals.  EVERY TIME.  That just doesn't seem like the best approach.

What happens when the song plays, LOADS the settings saved for that track, and convolution was off for the DSP SAVE for that track.  Would it turn convolution OFF (not what you'd want), and then back on when the song is over?

It seems like there needs to be a complete separation between DSP's that are set for the local player process GLOBALLY, and those that can be associated with individual tracks.  Otherwise I just don't see how it could be a practical solution for anything but a basic playback system where no global effects are being used.

What about adding a checkbox to the DSP Studio list?  The first checkbox would be the same as it is now, used globally.  The second checkbox would be enabled only for DSP's that can be saved per track with LOAD/SAVE and automatically activated as played?  Or perhaps a variation of that, but a way to designate what's global and what's not.  Global sets would never be SAVE/LOADed.

And VST's should be handled just as any other DSP.

Do you follow?



  • Galactic Citizen
  • ****
  • Posts: 307
« Reply #3 on: August 30, 2014, 07:30:52 pm »

The following exchange continued from Quick Polarity switching:

DSP Presets is a new feature in MC20. There is a new tag called DSP. In the DSP Studio there is now a Load/Save DSP button. This lets you switch polarity, for example, and then save as a DSP Preset. You could call it "Reverse Polarity." For all the songs that you want to switch polarity, you just click the DSP tag and select "Reverse Polarity." Now the polarity will switch on a song by song basis in a single playlist.

The current limitation is that the DSP stays switched until another song's DSP tag switches it to something else. This means you need both an Original Polarity and a Reverse Polarity DSP and all files need to be tagged.

The Zone method requires a separate playlist for each zone.

I don't understand the logic for this.  WHY would you want a DSP action to stay on from the first point it is activated?  To be a proper action for a given track it should turn on at the beginning of a track and turn off at the end.  Is this in effect trying to cover up some lack of speed or performance of the DSP on/off action?

The Tool AUTOEQ, though it had problems, didn't do this silly kind of stuff.  But it did suffer from slowness to activate and deactivate and was limited to one equalizer.

As currently implemented I can't use ANY of the DSP per track feature.  Not for just the reason(s) above, but because the DSP selection template used is the same as the global dsp defines for that play zone.  WTF?  Convolution, Room Correction, Headphones, would be controlled per song  or group of songs until it was eventually negated.  VST's as DSP's are completely disregarded.  You have to have unique control of each play zone (global settings) and separately settings that can be set/unset per track, regardless of what zone it's playing in.  It's TRACK DSP not SYSTEM DSP at that level.

I understand that a lot of the logic behind this is to reuse existing resources and avoid redundant code... But please, not to this extent.

Sorry guys, but it's currently Useless.


"WTF", "useless", "silly" ?! Pushing the right buttons there. What ever happened to "I have a suggestion, would it be possible to ..." or "I think it would be a good idea if ..."."

People are bending over backwards to give a very small minority of users some pretty esoteric functionality. Most people do not feel the need to change polarity on the fly, and most people do not need (or want) VSTs, not to mention changes to their EQ loaded per track.

If I were one of the developers,  I would not find this type of criticism either motivating or constructive. 

You may be correct.  But these are my opinions and I expressed them much milder than I was actually thinking.  So I guess that's my problem and your interpretation my vary.

If you have read this thread from the beginning, you'll see that I did start out trying to be objective about the issues and short-sightedness of this implementation.  However, the more people try to figure out a way to work with it, the more useless the functionality actually becomes.  To me it's a simple thing to logically determine how a set of circumstances would work given an objective.  I just can't figure out an objective that is solved by this solution without bringing up a myriad of other problems and busywork trying to make it work correctly.

"Most people do not feel the need to change polarity on the fly, and most people do not need (or want) VSTs, not to mention changes to their EQ loaded per track." 

Polarity aside, That's your opinion, which tells me you have no feel for just how useful this capability could be -- EQ *especially*.  MC isn't just for Joe Yokel out there in the masses.  The developers have demonstrated repeatedly that they understand the more esoteric needs of some users and genuinely seem to try to accommodate, with some features that I admit I can't find any use for.  Ever.  But that's ok.

That's why I am so irked when what could be very useful features (not just to me, but many others too, if implemented with some thought) get the short stick.  Sacrificing completeness for ease of programming just to get it out there.  That is SO below the talent that makes up MC.

Just my opinion, of course.

I'll try to come up with a bigger picture description of how I see it being the most useful to most that would need something like this and see if that helps.



  • Galactic Citizen
  • ****
  • Posts: 307
« Reply #4 on: August 30, 2014, 08:57:59 pm »

This post describes my ideas for what (I call) DSP-Per-Track.  I believe this would fairly easy to implement, and very easy, predictable and logical to use.

1. The purpose of DSP-per-track is to customize certain tracks which do not otherwise conform with your listening environment.  For example, insert some B52 songs in with some Daft Punk, and you hear a huge difference in studio and mixing style.  Some might say Daft Punk is too bassy others might say that the B52's music is very bright, hard, and on some systems almost irritating.  But they actually both sound pretty decent compared to other songs in each's genre.  So just as one example, DSP-Per-Track to the rescue.

2. DSP-Per-Track is completely separate from the regular DSP options which are unique to each play zone.

3. DSP-Per-Track only uses DSP options that are not global (intended for system use, like Headphones, Room Correction or Convolution).  Non global effects which logically CAN be used per track include Equalizer, Parametric Equalizer, Effects, Tempo & Pitch, and Parametric Equalizer 2.  Any user VST plugin loaded as a DSP may also be used (as they can also for play-zone global settings, but are still separate in function between global and per-track.

4. DSP-Per-Track is Library based, not Playlist based, so you are essentially tweaking your music library by song, regardless of where or how it is played.  That provides the most consistent behavior as well as ease of programming or adjustment.

4a. The Library based notion of DSP-Per-Track may be arguable by some, but having it by playlist means that the same song played in a different list would/could have different characteristics.  I suppose in select conditions that might be useful, but ultimately would be a whole bunch of additional busywork by the user, not to mention more memory required to house song parameters for duplicates in playlists.  (but see 5a for checkbox options.  One could be to make the same for all playlists).  I don't know how problematic this would be to program, though.

5. DSP-Per-Track would turn itself off after each track.  The idea is that this isn't a global repair of every tune in your library, but occasional corrections on an as needed basic.  Whole library changes should be done globally if deemed necessary.  Additionally, not turning it off on a per song basic would lead to unexpected results depending on sort orders.

6.  I suppose you could add a parameter to the name assignment of the DSP-Per-Track name, which indicated to NOT disable it and the end of the track.  But I'm not sure that the current naming of files for each DSP assignment is even necessary under this scheme.  Without separate filenames, It would be a simple right-click option from a library file entry, and that would show you the current DSP assignments for that particular song.  Additionally, you could leave that window open (much like playlists or tags) so it would show you immediately when a title is selected, just what its settings are (if any).  Extra unique options might be included in checkboxes for that filename.  Some sort of a visible tag (color?) could display in the file list to indicate any song that has DSP-Per-Track enabled.

6a. You could select multiple tracks and set the DSP-Per-Track assignments for all of them at once.  You could also copy/paste from one title to another to duplicate DSP.


Simply and easily 'normalize' various sonic characters of titles that just don't fit with each other when played together, whether it be eq, polarity, even mild compression when needed.  It would obviously be most usable when the sources are high quality, but could also be used to help blend mp3 or other lossy formats in with higher quality source.

Concise visualization of what tracks are or are not set for DSP, and quick changes can be easily made.

You could make up some nice playlists with tracks that fit nicely together, to save as a playlist, burn to CD, etc.

One of my uses would be when streaming live tunes to an Internet Radio Streaming station, especially tracks 1970 or before to get them more uniform in tonality and level (L128 doesn't work well for this) so that later processing will actually work.  This type of thing operates in real time and the music might span 4 decades or more, needing lots of help.

One professional use that would be helpful to me is for track mixing post production of a song, to modify it in various ways, and be able to compare them against each other or inserted in a playlist of other music to see how they stand up sonically.

There's lot's of applications for this sort of thing, but only if it is easy to work with, simple to operate, and completely predictable -- not subject to arcane limitations and behaviors that you're always trying to work around.

Anyway, those are my thoughts on the whole issue.  Comments?  (thought out, please)



  • World Citizen
  • ***
  • Posts: 106
« Reply #5 on: September 06, 2014, 07:34:55 am »

One thing that worries me is if the JRiver MC is focused on simple user interface for daily usage.
What most people would want is as easy setup as necessary for various levels of needs.  For example, you have settings to compensate for devices, and you have settings to compensate for recording setup, then you have settings to compensate for specific personal taste for specific tracks.

For device compensation, mostly are sound level ratio, polarity, equalization.  Pretty much each zone will have the same or different devices.
For recording compensation, mostly are polarity issues.  I think switching them when you want to is greate, but I would also like batch selection and processing to set this up for albums and tracks.
For personal taste preference, most likely this is equalization which you want for specific tracks.

I personally think how these are setup needs to be considered independently from a user perspective regardless what the underlying technicalities are.


  • Citizen of the Universe
  • *****
  • Posts: 508
« Reply #6 on: September 11, 2014, 04:40:09 pm »

I have had some thoughts on DSP Presets - why not make it like the current MadVR Profile groups concept. For example, you could create a DSP Profile Group of one of the Parametric EQs and give each profile a name which could be used in a DSP Tag for particular tracks or even a rule based Profile based on a condition.

Pages: [1]   Go Up