Amberwolf

If I could just tell the computer what I want and have it do that....

That's about the same reaction I get from JellyBeanThePerfectlyNormalSchmoo when my brother says "the dog" in some phrase referring to her.... :lol:

ok, i think i understand now. (my brain doens't work like normal people's)

A friend in Utah has to ride a bicycle in traffic on roads with holes that he describes as worse than those of old bombed out runways.... I don't ahve a picture of what he actually rides thru, but apparently som of htem are pretty bad based on a google image search I gather that some time ago, Texas tried out converting poorly maintained paved roads to gravel instead of fixing them.... I used to live in farm country in Texas between DFW and Red River, not far off the interstate, and almost all our roads were gravel, even in (the very very small) town. Some of the holes and other road conditions were enough to break vehicles unless they just crawled along or sped really really fast (enough so that they could lose control), and once the schoolbus was broken (axle or driveshaft, I dont' remember as that was a loooong time ago but it was very loud and the adults were very angry) not far from where it picked me up. We used to have "suicide hill" a ways down the road from my house, where the white (limestone?) rock shelf the road crossed was too hard for the occasional road grading to do anything to, so the sharp drop off there just got steeper and steeper as the top of the shelf was graded down onto but the part past it would get graded away and washed / pushed away by traffic and weather, down into a "gulley", making a very short but very steep hill. The bus broke going over that shelf. At some other point I was going down that hill belwo the shelf on a bicycle and skidded out in the gravel trying to avoid a hole or something, and tore myseful up pretty good before sliding to a stop at the bottom. One also had to sometimes avoid large bigger-than-head-sized fossils (and other rocks) eroded out of the limestone, usually ammonites, that could end up in the roadbed (sometimes having been in the roadbed and then pulled out by traffic or the grader, leaving a giant hole), or be sticking up out in the middle of a plowed field.

Thats not in this thread so I still don't undestand this thread's first post? Shouldn't it be in that thread?

Um, what post? Yours is the first one in this thread, and it is from today (11-16-2025)...I'm confused.

I have learned not to even bother visiting channels that do that, same as forum posters that post something useful, and then delete it. I've added many videos from various people to my watch later to learn from when I find the time, only to end up with the message "x number of unavailable videos are hidden", or have a bookmark to a video only to go back and find "can't find this" or "this video was deleted by the user". I've also bookmarked many posts in many forums to go back and read, only to find they're deleted by the user once I get the chance to do so. Whenever I can see or figure out which user it was I "block" them or "ignore" them so I never have to waste time on them again. Now I have another user / channel to add to the list. It's a waste of any user's time to go find things to learn from, only to have them disappear so that when they go back to learn from them and find they're not there anymore. Any content creator that does this is worthless for this reason.

For systems that are fan cooled, that's a fairly common cause of failures, by causing the fan to fail or inlet grilles to clog up, decreasing cooling to the point where heat begins to damage things. I've seen it in many many computer systems (especially laptops). But most audio equipment is not fan cooled (because that's usually noisy enough to interfere with it's intended usage), so it's not a common cause of such equipment. In old stuff, especially a couple of decades or more, and especially that is often left on (even if not active) for long periods, it's more common for elecrolytic capacitors to degrade or fail outright. In stuff that gets thermally cycled frequently with a wide difference between cool and hot states, fractures in the solder (or even PCB traces) for PCB-heatsink-mounted parts or transformers directly mounted on PCBs (vs wired in from off-board) aren't uncommon, and tend to cause problems in the cold state that don't happen in the hot state.

Whenever you put it up I'll see if it will register and operate here (occasionally in testing things like this I've found something that works on a dev system has a dependency that didnt' get packaged with it during compile), then I can play with it and let you know of any issues (or feature requests if you accept those).

Given the age, a faulty power supply to the system MCU or other logic is most likely. Extra noise in the low-voltage logic supply (usually 5v, sometimes 3.3v) from failing capacitors in the power supply PSU not filtering properly. That is usually a simple fix, replacing any of the electrolytic capacitors in the PSU itself, a few bucks' worth typically. Sometimes they show obvious signs of swelling or leaking, sometmes they look perfectly normal but have simply aged out as electrolytics have a limited lifespan--typically guaranteed for a certain number of hours at a given voltage / temperature depending on ripple current they experience (whcih is a lot in many PSUs, at elevated temperatures, decreasing the potential lifespan). Less likely, it could the ground issue, but probably not the same way. In this type of failure, it would be more likely that they use a serial data from that panel's own MCu to the MCU that does all the major systems control. The serial data in these situations is usually I2C (IIC) and if it is not all on the same PCB then a faulty ground or signal could cause this type of problem.

If you want to troubleshoot it, the most likely problem is one of hte buttons is stuck down internally (inside the switch itself, or a plastic bit from the panel has jammed between the button and the top of the electrical switch), or the ground (or other common wire) to the panel is broken or has a poor solder joint. Have had both of those cause this type of issue on various front panels of assorted "dead" thriftstore and yardsale finds over the years.

It sounds sort of like an automatable version of Variorum's "compressor" (if that one isn't already automatable). If it's available as a 32-bit MFX, I'd be interested in playing with it on my ancient SONAR . If it obeys normal automation data within a MIDI track (not just CCs within clips) then you could copy automation cuves you have created in other tracks to the track it's on and then reassign those to it's parameter(s).

BTW, for all the readers of the thread, there are, AFAICT, two separate MIDI routing systems within Sonar. If this is incorrect, please specify where I've misunderstood or gone wrong. The first is at the MIDI tracks themselves, and obeys all the track controls, etc. The second is the Remote Control system, which AFAICT without being able to test ATM, does not have any control over which ports or channels are received by or sent from a widget (on a track or inside a synth, etc), it globally recieves or sends this data on all ports. (possilby restricted to hardware ports vs synth's virtual ports internal to Sonar), restricted only by the channel selection when assigning a remote control. (which cannot be set to send or receive on more than one channel, AFAIK, no Omni option for instance; not sure if there is any reason to be able to have that ability). This system is used even if there are NO MIDI tracks at all, as you can use this system to assign RC to audio track controls, for instance, and that is almost certainly why this second system even exists. This second system is the one Astraios is having issues with, in trying to do external control of assorted things within his projects.

If you set a specific input port and channel on a track, only data from that should end up recorded on that track. If something else is happening, I'd call that a bug. If you require more than one device input to a track, the only way I am aware of is to set it to All-Inputs (either picking a specific channel or leaving it at Omni) If doing that, then without using some form of external filtering before it reaches Sonar), everyting on all the ports (and channel (s) chosen) would be recorded on that track. External hardware-input filtering could be accomplished by using MIDI Loopback type drivers, and passing all MIDI ports via those into a separate program that either does this filtering as a primary function built in, or hosts VST / MFX that can then do the desired filtering. I don't have any list of such hosts, but there should be some out there. (even other DAWs could be used for that purpose alone if they support the necessary functions and routing). All Echo does is Echo the input directly from the input selection to the output selection, for that track, regardless of playback or record states. It changes nothing about what is or isn't recorded to the track, or played back from the track. For instance, if you don't have the track armed for recording, everything will still be echoed from the input port/channel to the output port/channel, and will pass thru any track FX on the way. Even if you don't have the transport running, so that no track data is being output, Echo should still do it's job. (I think it will stop if the audio engine is not running, however). When echo is not on, the data cannot reach the output until it first is recorded onto the track, and then subsequent playback of those regions will output that data to the output port/channel. This is true of audio or MIDI. I have a feeling that is a separate issue from the track input selections and filtering. I don't have a way to test this here ATM, but you've already likely done enough testing to determine: If a synth (whcih is using MIDI Learn / remote control on it's fucntions) has been inserted on a track that is itself set to only receive from a single port still receives data from multiple ports, then that means the remote control is not using the track input selections at all, and a completely separate port setup and filtering system would have to be coded and built into Sonar to correct this issue--there would be no external way to deal with this without also blocking data from reaching the actual tracks themselves as well, becuase all ports are combined into the Remote control / Learned control system. If that synth does only receive data from that track's selected input port then all of the filtering options previously specified would work--but I expect from your issues that this is not the case. Same for track controls using Remote Control. If the former is the case, the only way I know of to fix this issue is for the bakers to recode Sonar itself to have a tool within it to allow the user to choose which ports and channels are used for each thing that is receiving or sending remote control information (the most versatile method), or for it to obey it's host track's port configuration (which would be problematic for some remote control usages), or some global configuration that all RC things use (extremely limiting and problematic, I suspect).

Those are even more important qualities for me than many others...anything that slows me down or makes it harder is much less likely to get used. I'm not interested in the Musio/etc stuff, but your statemetn still applies to any artistic tool.