Sections:

Document last updated 30 November 2007 by Dane


New Feature for 3.3 or Later, Added to List

New "TalkBed" feature. Don't even think about it right now! I know it's gonna be challenging and futurish.



TODO/FEATURE List

For 3.2



For 3.3 and Beyond (in no particular order)...

  •  # TALKBED   If it weren't for some of the things we've already done that would tend to lay the groundwork for this new feature, I wouldn't even bring it up, because it's clearly a challenging one. But given that some of this is already in CC's architecture, maybe it's at least a "considerable possibility" at this point.

    The idea is to allow for a "talkbed" (instrumental) to be played beneath a DJ-track. When invoked, it will cause any audio file to be layered over an instrumental. The instrumental gets killed, or better, quickly faded out, just as the DJ file ends. The syntax could be something like:

    /boot/Station/Promos/Promo3.mp3
    # Talkbed Comment JazzInstrumental
    /boot/Station/DJs/DaneScott_37.mp3
    /boot/Station/Music/SomeSong.mp3


    In that first scenario, the selected jazz instrumental and the Dane Scott track would start together. The talkbed would end and eject, just as the Dane Scott track ends. By including the atribute and value, it allows CC to rotate through all the available talkbeds, using a different one each time.

    Now...as if that isn't challenging enough already...

    What if we want the talkbed to surrender to the ramp of a song, as soon as the DJ file's remaining seconds is equal to the ramp time of the song?

    /boot/Station/Promos/Promo3.mp3
    # Talkbed Comment JazzInstrumental
    # VT
    /boot/Station/DJs/DaneScott_37.mp3
    /boot/Station/Music/SomeSong.mp3

    I'm not sure whether that's the best approach or not, syntaxwise, but the idea here is that as soon as the remaining time on the voice track is equal to the ramp time, CC would start the song in normal faded-down, voice-track fashion, and rapidly turn down and eject the instrumental track. I'm also not sure whether we're better off with a standard track or a hottrack for the TalkBed feature, so that's also up for grabs.

  •  USE OF TEXTBOX FOR STATUS NOTIFICATIONS   When Command Center is doing something that requires time to complete, such as loading a log, reparsing the log, doing a shift-space exact-time start, etc., Command Center displays a status notification in the scrolling text box. Light blue in color, large font to make it really jump out and be noticed. As soon as the task is completed, CC restores the previously-displayed text to the scrolling textbox. So it must store and remember the previous text's location so it can get back to it afterward. Example Image. I am suggesting we do this in a cool blue rather than using the hot red we use for error messages, since these new messages are saying, "everything's ok, just wait" rather than "uh oh, problems!" :-)

  •  VOLUMEDRAG AFFECTS EVENTS   When clicking/holding on a volume icon, and dragging the volume up and down on the big volume control, it's possible to accidentially drag events around in the listview if you're not careful. If your mouse cursor is a little too far over to the left, you'll see one of the events' drag boxes moving around. Happens with both the mouse and the touchscreen. This one may be fixed, I can't recall. I'll test it again when I have a new touchscreen and driver. I THINK it's ok.

  • SHIFT-SPACE OPTIMIZATION/b>   Doing shift-space results in a considerable delay as CC travels miles across the log recalculating running times. As we discussed, we can make this easier for CC to do quickly by calculating from the last # Interrupt/Hour statement instead.

  • SMART INTERRUPTS   Right now, if an infinite event fails, there is no good way to "fill" the leftover time between the start of the infinite event and the interrupt that...uh...interrupts it. Example:

    # hour 3
    # Live-For 99:00:00
    # Interrupt@:59:50
    /path/StationID
    # hour 4

    If the Live-For silence-senses, we go slam-bang into the StationID and hour 4. Not the best situation. Ideally we should have something like this:

    # hour 3
    # Live-For 99:00:00
    /path/music/song
    /path/music/song
    /path/music/song
    (etc)
    # Interrupt@:59:50
    /path/StationID
    # hour 4

    TuneTracker should understand that if the infinite event fails prior to the interrupt, it should advance to the very next event on the log. You might say we are "resetting the interrupt."

  •  SS OVERHAUL  Cedric, is this one done already?  "GREY-OUT" AND GENERAL OVERHAUL OF SILENCE-SENSOR PREFERENCE GUI: Cedric sez:* there is indeed no BT-box equivalent to our "threshold" configuration parameter.. this will have to be greyed-out or something, when in BT mode. * there is (somewhat) an equivalent to our "duration beneath threshold" configuration parameter: one may set it between 2 and 9999 (!) seconds. To make things easier, maybe I'll outright change the widget within the tunetracker Preference Window, and make it a BSlider instead of a BTextControl... It looks good (tried it in another C++ project of mine) and would make things streamlined. * there is, even, a setting which "we" do not have, that was unknown to us before: the "duration of active noise before REsetting the sensor" setting; I guess we'll probably just hardcode it to 2 seconds or something, to keep it simple, though we could choose to implement it AND retroactively implement it for SoundPlay as well, on the other hand... Maybe when having less of urgent things to do.

  •  SHUTTLEPAD TOUCHES ARE FUNKY   This one's a little spooky... :-) ShuttlePad displays, or doesn't display, the contents it is holding, depending on what other items I touch first. The strangest part is that it doesn't seem to follow any predictable pattern. Sometimes if I touch ShuttlePad (no result) then I touch, say, a hotbutton, then re-touch ShuttlePad and get a result. Other times I can repeat the same process and don't get a result. Ultimately I have found that if I touch enough stuff, or the right stuff, then go back to ShuttlePad and touch it, it displays its contents in the textbox. This might be beyond the reach of mortal intervention! I'm using the touchscreen driver you sent me April 3rd.

  •  HOUR ZERO IMPLICIT   Let's see if we can get rid of this. It's not that big of a deal, but if a way can be found without it getting long and frustrating, it might help avoid some potential confusion for the user. If this needs to be pushed into 3.3 to keep us on schedule, it's ok.

  • REVISED LISTVIEW DISPLAY  Title larger and on first line. Artist stays current size and goes to the second line. Running time text edged down slightly. The word RAMP: is removed entirely. See illustration. CEDRIC NOTE...Let's NOT jump ahead and do this in 3.2. We will want something visually different and interesting in 3.3 since much of the rest of the 3.3 features will probably be "invisible" to the GUI.

  • EXPIRES ATTRIBUTE  "Expires" would be to prevent an outdated file from playing. Command Center would compare the date (and time?) in the Expires attribute to the current date (and time) and if the Expires attribute is older, that cut would not be played. We would log all Expires to the output log, something like: 10:33:00 The cut "$" is expired and was not played.

  • LASTPLAYED ATTRIBUTE  Command Center would be given the ability to log the start time of every played audio file, written directly to that audio file's LastPlayed attribute. This would serve many useful purposes, not the least of which would be a solid way to know whether TuneStacker is "playing fair" when doing randomizations. Initially I suggest we use this as an internal test mechanism, and eventually, if we decide to, make it available as a public Preferences option that can be turned on and off.

  • EXPANDED INFO FEATURE  If this isn't too hard to "compile" into a single text file, we could use the Info feature to display more attributes than just the Info attribute. That way, if no Info has been typed-in for the song, at least there will be some good basic information available about the song.

    INFO:  Joe Smith dedicated this album to his wife, who was pregnant with "Little Joe" Smith at the time. Little Joe grew up following in his daddy's footsteps, and eventually had his own successful recording career with the group, "Little Joe and the Farm Hands."

    ARTIST:  Joe Smith
    TITLE:  Georgia
    ALBUM:  Southbound Train
    GENRE:  Country
    TEMPO:  Medium
    COMMENT:  MorningsOnly
    RATING:  3
    PLAYING TIME:  2:48
    RAMP:  :17

  • SWITCHER "SALVO" FEATURE  More than one user has suggested we make it possible for a single configurable button to handle more than one switcher switch at a time. So it would be possible, for example to assign two or more switcher events to a single button click, resulting a channel 1 being routed to output 2, channel 3 being output to channel four, and channel 3 being output to channel five. What would be needed, I assume, is an "Add" feature in the area where the buttonpad and myshow switcher preferences are set. In terms of GUI, I picture something similar to what happens when you add more query layers in BeOS' Find window, or more protection layers in TuneStacker's ProximityGuard window.

  • LIVE EVENT BUTTON DOESN'T TURN OFF  Cedric sez: The "live" button does not come back up when a #live-for event terminates on its own... At least not as fast as it should -- this is because the concerned'live' track is STILL within SoundPlay, though in a "stopped-playing" state ! I'll have to implement the "clean up expired tracks instead of leaving them to linger" thing... Confirmed in testing here on 10/12/07

  • SHOWTEXT FOR WEB-BASED SCRIPTS  "For a lazy winter day sometime": What we presently do... # ShowText /boot/home/SomeTextFile.txt What we might add as new functionality to the command: # ShowText http://www.someurl.com/SomeTextFile.txt

    cedric sez: [the code for this will be similar to the "quicktip" one, but] The QuickTip uses a "hardcoded" (well known) filename, whereas for this one I'll use the same external program (/bin/wget) but I'll have to write a little code routine that computes the "filename" from the URL, for instance "SomeTextFile.txt" in your example below, create a temporary directory within /tmp (so as to be clean and system-friendly and all) and download it.

  • RELAY BUTTON PARAMETER: URL  This lets people put an item on the air from a remote stream by just clicking a custom button on their screen. The behavior would be to relay the URL as a floating hot track, until the user kills it manually. The hot track relay event would have a volume adjustment on it, just like any other hot track.

  • NO AUTO IF NO LOG:  One nag I should change for sure: the Auto button should stubbornely refuse to become "highlighted" if there are no logs loaded.

  • DRAG-N-DROP TO CONFIGURABLE BUTTONS  to set them in one fell swoop
    Date: Mon, 10 Oct 2005 13:20:47 -0500 To: cdegea@free.fr It would be very handy for the DJ if he could drag-n-drop from Tracker, Lightning, heck, even from the event listview, directly to any one of the JockPad buttons, to assign that file to the button automatically. When they do, the JockPad button's text would light up momentarily as the dragged item is passed over it. When dropped onto the button, TT would assign that file to the button, as well as detect the filetype as either Text or Audio and assign it as the correct type of button automatically. The button menu also popus up right away so the user can manually enter a label for the button.

  • OUTPUT LOGGING OF GETPLAY:  e.g. # GetPlay /boot/Station/Programs/Into Tomorrow/%D.mp3 should instead print the (computed) actual path. Given the current state of the code this is not possible, since LogInstructionLine::OutputLogRepresentation() does not know the current "TimeCookie" and thus cannot possibly call LogInstructionLine::GetSongPath(). Rather than hack it, I'll have to re-organize the code so that the TimeCookie is passed somehow.

  • OUTPUT LOGGING OF OVERLAY:  We should also log each Overlay event to the output log. This is important because Overlay will be primarily be used to play station IDs, and the station IDs must be logged to prove they played, for legal reasons.

  • VOLUME BOOST SYNTAX MADE AVAILABLE TO ALL LIVE EVENTS   This is going to be a rather major change, I suspect, but I want to be able to add a "command line style switch" to any audio event, whether live, relay, or digital audio file, to boost its volume by a given amount. I am not opposed to doing this with a line just above it that says something like, # Boost 4, rather than putting the syntax on the same line with the event. I'll leave it up to you to decide what sort of numerical values to assign to this.

  • Even though I had struggled against this suggestion from Dane for about a year, I'm now finding that it would be way more consistent to not fill-out the green button "cut lengths" at startup time, but only as RunningTimes gets running . This would speed up startup, and allow me to have more consistency in the code, and provide better accuracy. Is this still valid?

  • FINISH OVERLAP:  If there are ramps on either side of a voicetrack that equal more than the length of the voicetrack, the answer is that we should split the overlapping 50-50 between the preceding song and the following song. "" Is this still valid?

  • EDIT BUTTON SELECTS CORRECT LINE  Pad editor: contextual-menu should open the tree-editor AND pre-select the right line in the treeview.

  • KISSLIB BIGGIE : EXPANDABLE KISSTREEVIEW  (used e.g. to configure the ButtonPad and MyShow) should implement the collapse-subtree/latches. Dane: There are some down-pointing arrows along the left side of listview in the editor windows that make it look like it should be possible to expand and collapse the sections of the list, though that doesn't appear to be implimented. That would actually be a *really* nice feature, since at a station with multiple djs using multiple sets with multiple pages, the overall list could rapidly get very, very long. If the list could be collapsed by sets, and also by page, that would make it easier to work with.

    Others, to discuss and decide on a timetable for...

  • TODO: implement *multiple* file refs in DnD of mp3 events et al

  • TT "professional" enforcement?? Didn't work on that in along time..
  • new Contextual Menu in PadEditor.cpp (with "make this set active" ..etc) Dane: > > - I wonder if we should give the user an option right in the Buttonpad > > editor window and in the MyShow editor, to choose which button set to > > display. Maybe we could make it possible to right-click on the name of a > > set in the editor and choose "Display this set in TuneTracker" or > > something > > like that. Cedric: > The editor as it is today we get "for free" since it is provided by > the kisslib, but customizing it involves recoding it (somewhat) > from scratch, which is a multi-days project... > Unless... hmm... unless I get away with triggering the display > of the pop-up-menu via one of those nifty BMessageFilters, > which would save me a rewrite of the whole thing and just > "piggy back" the menu on top of the rest... > And while we get to do this right-click menu, might as well add > things like "cut" into it, so that it doesn't look too "short"... Anyway, > can look into this if you want. But the "long" way (rewriting from > scratch) I hope we never have to do :-)
  • IMPLEMENT "macros" so as to be able to read that kind of alias, from a config text file: # TimeAndTemp = # TimeAnnouce + # TempAnnounce
  • Later: make a LISTVIEW instead of 3 boxes in Prefswin for transitions, and then add a syntax to access custom made transitions like e.g. #transit NORMAL /some/mp3/path except that it's the _talk-over_ that needs to be marked, or TuneStacker will have to do more inference/decision/intelligence..!
  • To make the F10 key's behaviour persistent, add "__ Display Memo Lines" as a look and feel preference.
  • "Cue" (i.e. make volume-controls able to /pre/ set volume for an /upcoming/ T0)
  • LOOK/FEEL: Make the text-view use a CustomScrollBar, not a BScrollView.
  • OPTIM: optimize BlockyListView::ScrollToIndex(), which restarts from the beginning of the model each time (!)
  • CUSTOMIZE VU, replicating SoundPlay's pop-up menu as-is: we should be "" letting the user choose from one of several VU meter backgrounds in preferences.""

    cedric's estimate: probably not hugely long to implement, but still about 10~15 hours [have to dynamically-re-layout the whole GUI when the size of the VU changes].

  • "" Add an option in preferences that results in the adding of a line to our BRS reboot script that will cause the launching of our "persistent weather updating" script. The line can be: /boot/home/config/bin/UpdateWeather.sh &
  • BUG ACKNOWLEDGED: an #interrupt happening e.g. at the very beginning of a TuneTracker session, or whenever else there is nothing loaded up in SoundPlay, will properly add the "IRQ'ed track" but fail to *schedule the rest of the automation* due to a lack of EJECT from the proxy (since there is nothing to eject yet since this is the very first transition)..
  • ToneTracker RELAY INTERFACING: The Broadcast Tools box also has a set of relay connections that are *outgoing*. They are used to send a relay closure *out*. The outgoing relay closures can be used to control external devices, and with a little creativity, can be used to do almost anything...from starting a tape deck to starting a reminder alarm, to turning on the coffee maker, to lowering power on the transmitter. # SendRelay 1 Using this simple behavior, we would just send the relay when CC arrives at the event, the same as playing a song. In the example above, when CC reaches the event, it would send a relay closure to Relay 1. However, what if the user wants the relays to happen at very specific times in the hour? In that case, we can't rely on the behavior above, unless we interrupt the music to play the relay, which would be downright stupid. :-) So I propose we have eventually do a second relay command that behaves kind of like the PlayOver feature... # Relay@:15:00 1 Now let's take that thought one step further. Suppose we had a standard music hour. 1000 ..just lots of songs. But at four times during the hour, we wanted to send out a relay at a very specific time. Obviously, it won't work to just scatter the # Relay@ events through the hour, because the time at which CC arrives at each is unpredictable, and if it is arrived at prematurely, then what? So I think a better approach is to put them all at the end of the hour and require CC to be smart enough to look-ahead on the log and handle them as they are needed. So it might look something like this: # Hour 1 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 /path/Song.mp3 # Relay@:05:00 1 # Relay@:15:00 1 # Relay@:30:00 1 # Relay@:45:00 1 ## End of Hour For the same reason, it would probably make sense for all of the PlayOver@ items to be placed at the end of the hour, after all other events...but again, we're getting ahead of ourselves a little with all of this, because I assume the new behavior requried for PlayOver@ and Relay@ would require some serious revamping...and probably is more than we can mess with right now. So, concluding! The two that we need initially are... # Listen-For 00:30:00 1 (monitor a particular relay channel for the time specified and respond with a panic if a relay signal is received) and # SendRelay 1 (send a signal to the relay specified)

    Dane adds: I spoke with the company, and found out how outgoing relays are triggered. Sounds really simple. To send out a standard one-second relay closure, all you need is the word "Pulse" and the relay channel to send it to. If, in the future, we ever need to send a longer relay closure, we can use a feature called "Latch" to hold a closure for as long as we like, until we send a second Latch command that discontinues the closure. As for the particulars of syntax, I'll refer you to their manual, which is what Ben used for reference when putting in the commands ToneTracker uses to do its other magic. Once you start looking over the available commands, lights will undoubtedly start going off in your brain, and before long, you'll be telling me, "did you know it can also do... this...and that...and the other thing??!!" :-) One thing you *will* see in there is a way we can tell it to do a fade-in or a fade-out. Not controllable by a slider. It's a default five-second fade-in or out. But it might come in handy. Anyway, here's the link to the manual... http://www.broadcasttools.com/manuals/Manual_ACS8x2Plus.pdf

  • Improve some more our already existing "Start at exact place" feature so that it's the be-all-end-all out-of-this-world implementation it could potentially be :-)

    Cedric sez: It would be a relatively easy step to "go the extra mile" and also enforce a super-granular (second-granular rather than song-granular) approach. E.g. Tunetracker could actually wipe out all songs from soundplay, and make it load up the one song that is supposed to be already playing, and move the blue-bar progress cursor in soundplay to the precise second the song ought to be located at (!). If we ever implement such an "extra mile" for this feature, we'll probably want to wait until the "Auto On" button is depressed before doing the wipe-out/recreate thing... And how do we deal with scenarios where the user does NOT want it to happen this way..

    Dane sez: I have actually had people ask for that feature. Several thoughts on it... 1. I like the idea, but would only want to see it implemented for reboot recovery, and then, only if the option has been selected in preferences. For instances where the power goes down and back up during the middle of a long audio file such as a concert, this would be a tremendous benefit to stations that specialize in that sort of programming. 2. As intimated in #1 above, I wouldn' 1000 t want TT to have that behavior every time a log is loaded. That would be too "powerful" and potentially create more problems than it solves. A hotkey that does a forced update to an exact track and playing position would actually be an ok way to handle it so that the user doesn't have to resort to rebooting (per #1 above) if they did need to force TT to go to an exact-second-level-granularity in order to get programming back on track. If we did assign a forced update to a hotkey such as athe letter "u" on the keyboard, we might want to have a confirmation box before actually doing it. Otherwise accidentally bumping the "u" key (or whatever) would be an exasperating mistake. :-) 3. At least as important is that we find a way to be to-the-second granular on our live events when we reload a log. TT needs to become very smart about where it needs to be in a live event when a log is loaded. Right now, it's very challenging to get TT to go live at the right place when loading in a log that indicates we should currently be live. I understand why that is difficult, with the various ways we go live, such as sometimes using Live-For of a specific length while other times using an infinite live event and an interrupt. But since we can calculate running times, it seems to me TT should be able to also calculate when an event should go live, which minutes it will be live, and when it will cease to go live. Thus it should be possible for it to know if it should be live right now, and for how much longer it should be live. So my question is, is it possible for TT to start viewing live events kind of like songs and other audio files, fron the standpoint of calculating what it needs to do when going live following a log reload...essentially "joining a live, in-progress" and correctly staying with it until the end of the live event?

  • Improve the existing "Open Log With Editor..." feature to 'go the extra mile': Do a little basheroo like this, to reload the log to take the user changes into account: When StyledEdit is closed by the user, there would be an Alert that says, "If you made changes, would you like TuneTracker to reload the log now?" If yes, we'd do ttreload, otherwise we'd just close it.

    Cedric sez: Something like, StyledEdit /path/to/the/log if [ alert "If you made changes, would you like TuneTracker to reload the log now?" ] then ttreload fi If I was more of a bash wizard, I'm sure I'd find even a way to avoid being clumsy asking "if you made changes...." at all, and only display the "/bin/alert" *IF* the user indeed made some changes - -this would be achieved by comparing the "time stamp of modification" of the file before and after StyledEdit is invoked or something.

  • Fine-Tune output-logging (for RelaySwitcher et al): Let's log something like: 00:00:00 Switcher 1 On - NBC News 00:05:01 Switcher 1 Off By the way, if it doesn't complicate life too much, we can logically eliminate the "Ramp" entry from all of the following: Automated Live events Automated Switcher events All HotTracks launched from ButtonPad and MyShow Live events launched from the ButtonPad
  • Implement "trimming" of mp3 ..etc files, i.e. allow the user to "virtually" trim audio files by adding a mere attribute instead of having to go to soundforge or BAMBAM or something and have to edit the file itself. The BFS attributes would probably be named "tunetracker:trim_begin" and "tunetracker:trim_end", type float, expressed in seconds.
  • Implement the "TrimFront" and "TrimBack" attributes and support code.
  • The ever-difficult volume-boosting feature thingy (Cedric buries it down here in the hope that Dane will forget about it *grin*):

    Break compatibility to add "volume boost by +1.0 or even +3.0 ..Etc": > > * we limitate the scope of this +n argument (to only > > relay-for and live-for, e.g.) and make its syntax "coder-friendly" > > by shifting it to the left like thus: 1000 > > # live-for +3 00:02:00 > > Sure! That'll be just fine. Go with the "shift-to-the-left" approach. :-) > Not sure we'd need to break compatibility, would we? Can't TT just assume a > value of +0 (no change in volume) if a + value isn't given? I've seen lots > of command line programs that assume a particular value if it isn't included > by the user as a command line switch. Command-line tools are a whole-no-ther-can-o-worms :-) They use the "getopt()" API function, described here, file:/boot/develop/headers/posix/getopt.h which is a little beastly to use, though it allows for very powerful (from the user point of view) feature. Heck, even in the "keyfile_gen" command-line tool I've provided you with, the one used to generate keyfiles for TTCC, I didn't use it even though it was supposedly THE place to use it... So I'm even less confident in using it in such a complex animal as TTCC :-) Okay let's see - - I'll get back to the drawing board, and try to come up with something that is both simple for me to implement (meaning it won't lead to instability or bugs or maintenance hell) and powerful (or at least unintrusive) for the user... Maybe I can put the +n argument to the right rather than the left, of course "optional" (omitable), and to the left for the other syntaxes, and the hell with "consistency".. Or if we need consistency, maybe I'll come up with a "#boost-next-line-volume" contextual command or something.

    A previous feature-request from Dane expressing something similar: WANTED: New Optional PARAM to #relay syntax - Add a switch for our relay-for feature that adjusts volume to something higher than the standard volume, maybe like this: # Relay-for Duration IPPath VolumeIncreaseAmount So in use, it might look like: # Relay-for 00:33:00 83.102.88.12:8000 +2

    And yet more: If we express the volume as a + amount, then TT will always know that what follows the plus sign will be the amount of extra volume to send to SoundPlay. This is necessary because often "feeds" coming from other sources are not sent at full volume, so when relayed, they're "weak" and don't match well with the volume of the rest of the station's programming.

    MORE : Dane wants the same additional param for LiveOn and play as well: ============= ================================== > Regarding the 3.1 Relay volume thing, I was thinking that whatever we dream > up for this should be kept flexible enough to apply to other items as well. > For example, some stations complain that a certain news service's newscasts > are always too low. So maybe we can also have the TuneTracker equivalent of > a Play command, called something like "# BoostPlay" ... > > # BoostPlay /boot/path/filename.mp3 +2 > > Similarly, sometimes the signal coming into Line-In isn't quite strong > enough, so we could also do this... > > # Live On +2 > > As to the specific syntax, I suppose that could also be something like: > > # Live On Vol +2 (??) > Alternatively, we could use the on-disk mp3 file attribute > coding for such level-boost (there exists one, gotta dig it up), > so that users don't have to modify every single line of > their master-log referring to "/boot/path/filename.mp3" with a "+2" > (and *I* don't have to handle those PITA syntax thinggies :-P) > but just have to edit the attribute of that very file... > > And thus the boost would work also when the file is not > hardcoded in the MasterLog but instead generated into > the proglog by a "Random Jazz Protect" master line or some such, > since the boost would *not* be dependant on the generated line's syntax. > > Either TT or SP would have to read that attribute (SP is > already able to, I think) and boost up the SP volume > knob accordingly. > > As to #LiveOn, why not make it a PreferenceWindow thing, > again so that every single invokation of LiveOn enforces the > setting (whereas one co 1000 uld easily forget to add a syntax-line argument..). > > Hmmm.... How do those ideas mesh with real-world usage & needs ? They're all good, creative ideas...but they have their merits and their drawbacks in a real-world situation. :-)... In the case of line-in, some stations use a rotary dial to choose from multiple input sources feeding the line-in...so their volumes vary. Thus TT should be smart enough to compensate for the line-in levels expected at varying times of the day. In the case of using MP3 attributes to hard-code volumes to the files, the problem is that the most unpredictable-volume files are those that are auto-downloaded from the web...coming from other sources and at times when nobody will necessarily be there to add attributes to them. The files found randomly must be properly engineered to start with...since no radio station's automation can be responsible for tweaking every song in a library as it is playing back. Definitely, I think, the per-line-in-the-master-log approach would be preferable, if we can pull it off.

    UPDATE: Dane eventually agreed to have an on-disk attribute: Here's the "spec" I responded with: So if we are the "only" ones using it, I have all the freedom I need to spec it: Me, c.d., in my quality as grand ayatolla of TT code, I hereby issue the following edict: Whereas a so-called "Audio:VolumeAdjustment" mp3 BFS attribute currently exists, and may be edited either by downloading the "audioinfo" plug-in from bebits, or (better) outright configuring OpenTracker to display this attribute just like it does others, Whereas the Audio:VolumeAdjustment attribute of type int32 is known to have legal values in the -4.....+4 range, Whereas we wish for its value to have the following semantics: 0 is mapped to SoundPlay's normal "1.0" volume, and +4 is to be mapped to SoundPlay's "2.0" maximum volume, It is heretofore claimed that the following change will have to be done to the TuneTracker code, at a later date of our choosing: 1) PlayerPerformer/SPProxy's handling of so-called "physical files" ought to read and take into account the aforementionned attribute, 2) It should thus "patch" the volume value it has received from TransitionEngine (in the 0.0.....1.0 range) with this formula: patched_volume = volume_param + (attribute_value/4)*1.0 End-of-Edict. :-)

History

This is the so-called change-log, especially useful to Cedric so that he may play smart-ass and reply to Dane's inquiries with stuff like "oh yeah, feature xyz is broken, I know about it for sure, had regressed back in 3.0.19 days back on 2007-02-28, been planning to fix it ever since", errr... This section is especially Cedric's responsibility to keep well-maintained, for his own sake (and Dane's :-). All history-entries are to be dated and of course build-version numbered.

3.1.11 "carload" (2007 10 20)
Truckload of small thingies, this time..
  • CrossFader feature "feel" now implements click-n-hold: the user now must hold down LMB for a second to invoke the crossfader, otherwise the old behavior is used instead (i.e. start song with full volume from the get-go).
  • EventLine: Fixed the "LMB click-n-hold will trigger the GetSongInfo" feature "Feel": it now no longer requires knowing the "secret handshake" to trigger it after holding the button for 2 seconds... J/K, but hey, the previous implementation was indeed shaky. Things have changed now thanks to the little brainstorming I've done for the "crossfader click-n-hold" feature -- /that/ feature and /this/ feature now rely on Pulse(). I'm not a big fan of the Pulse() callback :-) but gotta admit the implementation should be reasonably robust and reliable thanks to it.
  • Made the CrossFader display "pixel perfect". E.g. found that I had to inset the window rectangle by 2 pixels horizontally and 3 pixels vertically to define the inner "cursor gadget" rectangle.
  • Optimized the CrossFader display a bit to make it consume a little less CPU.
  • Prefs GUI: neatly re-organized the "Misc" pane a bit. The look-n-feel prefs are now together (VU and Localization are grouped at the bottom). Broadcast ops is still at the top. A new BBox group has been created inbetween: "Preview", with the combo-box-previously-known-as-audition (and now named "Soundcard") with the following help string: "Which soundcard to use for Preview output (most likely select one separate from the 'broadcast' soundcard!)."
  • Fixed the Overlay "dupe invokes" evil bug occuring when reloading a log: the TimerRunner destructor was never called, due to an arcane C++ "feature" (lack of cast meant incomplete delete job).


3.1.10 "a little snapshot" (2007 10 11)
..
  • CrossFader: New Gadgetry PNG pics: now using a 324 pixels background and a 63x63 instead of 77x64 pixels slider gadget.
  • CrossFader: Extended the CrossFader feature to green buttons (i.e. it's not only for Gold-button n2p any more). Look-and-feel wise this is less "perfect" than in the case of the Gold Button event, since green-button events are propelled up to the top of the listview when invoked, but people using this feature will most likely focus their eyes on the CrossFader itself and not on whatever happens left, so this should be no big deal. The only "keep an eye on potential problems" warning I can think of, is the Ramp Countdown: people might potentially need to watch the countdown as they cross-fade, and in the Green Button case that would involve a bit of eye "gymnastic", so to speak.
  • CrossFader: Modified the "slider gadget" grab point: it's now center, instead of far-left.
  • CrossFader: Added some math safeguards, bracketing the crossfade value between 0.0 and 1.0 (it could go a bit "wild" in the previous build).
  • CrossFader: fixed the popup's starting location (for "green" event lines, "gold" ones were already fine): the clicked button (be it green or gold) will now send its coords along inside its invokation BMessage, so the CrossFader BWindow builds itself correctly.
  • CrossFader: ejection of "older track" is now longer systematic -- now depends on the terminal position of the mouse (and thus position of the slider gadget): if fully to the right, eject, otherwise, oldertrack is left running as a hot-track, with its (yet-remaining-from-fade) volume intact -- could be useful for some special purposes fades, I understand.
  • While toying around, managed to reproduce the Crash (SegFault) in EventsModel::MsgRcv(), that's weird... Anyway, added some ASSERT() in case in happens again, will know for sure.. Dane if you manage to "hit" the ASSERT()s (i.e. manage to crash it in there again), this new build will give more info to the programmer, it will give a bone to me :-) so that I may fix it -- the prev build lacked useful ASSERT statements, too hard to diagnose.


3.1.7 "new car" (2007 09 12)
What doesn't kill you, makes you stronger, they say :-) So I'm back and kicking! This build should be very very close to production-quality (was about time!) and with a new feature to boot.
  • Pre-settable volume levels: Good as done. Careful when using though: if an event is in #fade-in context, the user-specified preset will be superceded by the fade-in command. Can't think of any other problematic scenario except this one... The thing seems to work pretty well. Was a kinda major undertaking and took 2 full days to code though, but now it's done, enjoy it :-)
  • Probably fixed the reboot-recovery "song granular" cursor placement: during recent changes, had forgotten to issue a call to transitionEngine->SetActiveEventIndex_AsPerSimulatedEventIndex() before issuing a call to transitionEngine->StartActiveEvent_AsPerSimulatedSeekOffset() , resulting in silent failure of Seek in the latter and thus NO song-specific placement at all, but mere "time correct based" cursor placement instead. Have now added the missing call.
  • GUI / PreferenceWindow: changed labels; "Calculate next-to-play event based on..." to "After reboot, start log at..." "Best-effort (from start)" to "Nearest event" "Best-effort (jump in)" to "Nearest second (mid-event)"
  • Probably fixed a bad interaction between the BeOS registrar (BTimeRunner "server") and TuneTracker, impossible to reproduce-at-will but with deadly (as in "dead in the water") consequences should it happen. Was prompted to do this after experiencing something very similar to a rare bug reported by Dane, whereby his TTCC had failed to start cuts for 10 or 15 times (as if the Media Server had crashed or something), and then resumed working out of the blue after a few minutes : saw something very much like this after doing some "panics" (spacebar hits to go to next song), except my TTCC never recovered, it remained dead :-) Techie note: as a "note to self", never leverage two timers both set to the same time and expect them to always be triggered "in order": the registrar might sometimes time re-arrange them for some reason, meaning you're S.O.L. (i.e. the NO_POLL "stop old track and start new" thing is never done ever after).


3.1.6 "all apologies" (2007 09 01)
Dang... Sample-station'ed this one, and didn't take long to realize my implementation of the #overlay "pre scan" feature had messed up some other code. Was quick to track down fortunately.
  • GUI / volume knob: changed the useful volume range to [0.0 ~ 2.0] (i.e. it's now capped at 2.0 instead of 1.0) so that the user may tap SoundPlay's "volume boost" capability.
  • GUI / volume knob: change the mouse-tracking behavior to what is (probably) it's final, best-practice implementation :-) -- tracking now starts when the mouse pointer enters the BView's bounds for the first time after mouse-down, and then never stops until the mouse-up event. Had to use the B_ENTERED_VIEW code feature though, which I seem to recall Zeta doesn't like all that much...
  • SS "immunity" for pause: Ended up implementing this in a different way than first envisioned, with a flag in TransitionEngine. From this build on, whenever a pause-for is the "PrimaryTrack()", it will 'veto' any silence sensing (BT-box or soundplay based) until the PrimaryTrack() changes to something else.
  • Fixed a stupid bug in ProgramLog::gotoFirstLine(): after running 3.1.5 on the sample station it was obvious I had broken the CurrentIndex() management within program-logs (during my recent #overlay implementation), making them sometimes off-by-one. Fixed. This affected much of the GUI, since it mostly relies on "index" ID rather than "line-number" ID: running times, next-to-play, double-click-to-make-next-to-play, you name it.


3.1.5 "danger will robinson" (2007 08 20)
Another package from the "quite a bundle" department... Here's hopping that I under-promised and over-delivered, contrarily to the federal reserve bank :-P ("which is none of the above", infamously). LAST MINUTE: witnessed a bug, similar to one Dane had previously described to me, though couldn't find a reliable way to reproduce it tonite: it would seem that, if launching TT and then toying with the listview scroll-knob, and then hitting SHIFT-Space, the created GUI event-line will incorrectly display a starting-at-beginning progress bar, instead of showing the same progress ratio than the one effectively assigned to SoundPlay's track. And it would SEEM that the GUI is not affected by this bug if one hits shift-space directly (no touching the scroll-knob).
  • Fixed the last remaining #warning I had set for myself in BigMainWindow.cpp: made the "command-arrows" keyboard shortcuts code more modular. No functional changes.
  • GUI / Big-ass volume knob and slide: in trying to tackle the "pre-settable volume levels" feature request, I've started to kinda fix (and break...) the volume slide knob. It used to jump up to the top whenever invoked, "forgetting" what the actual SoundPlay volume is -- it will now directly query SoundPlay before displaying itself, so as to be 100% foolproof (even if the D.J. changes the volume "behind our back"). The catch is, I had to disable the call to SetMouseEventMask() though (the "monitoring anytime, anyplace" mouse pointer monitoring), so things are dicey, ergonomy-wise. When I get back to this, I'll probably want to re-enable the SetMouseEventMask() call, but only after the *first* entry of the mouse pointer into the GUI widget, so that we have our cake and eat it too. Will get input from Dane to see what he prefers.
  • Fixed a tiny GUI glitch with the drawing of the progress bar of event-lines: the grey area that is expanding right as an event plays, used to be offset one pixel too far to the right, leaving a bright vertical background line intact to the left. Fixed.
  • Fixed a subtle Scrollable-TextView display bug: the scrollbar used to get "out of sync" with the scrollable area if "Enter" (enlarge/shrink) was called from a state other than scroll-knob-at-the-top. (didn't know I had to call r.OffsetTo(0.0, 0.0) before calling SetTextRect()).
  • Under the hood: refactored and cleaned up some code in the ActiveEventProxy hierarchy -- moved the StartPerforming() code into ActiveEventProxy::StartPerforming(), as a "lowest common denominator" to all the variations that used to exist.
  • Overlay: changed the 'licensing' of the Overlay feature: moved it back to the "no special license required" zone, instead of it requiring a "TT Pro" license field flag.
  • Overlay: modified the Overlay syntax: it is now a fully-qualified "hh:mm:ss .....", instead of the older partial ":mm:ss .....".
  • Overlay: modified handling: they're now "pre scanned", wherever they are in the log. They're never stumbled upon while automating, only ever read at "pre scan" time. The user may put them all at the top of the log (which makes sense, given the new syntax), or may put them in their respective "hours", though careful not to put an #overlay 17:00:00 in a block that starts with a #hour 16 otherwise I can imagine the headache trying to imagine "why the overlay feature does not work correctly"... until the user figures out he did not "match" the right hour statement with the right overlay statement :-) Anyway, it's simpler and fool-proof to put them all at the top of the log I guess.
  • Overlay: they now apply only in "Auto On" context -- made them go through TransitionEngine first, before hopping to EventsServer, so that TransitionEngine (which knows about the automation status) may "veto" events before they reach EventsServer (which does not).
  • Overlay: the "pre scan and set timers" routine will ignore any Overlay that are "in the past". Of course. Would be havoc if all the "overdue" overlays fired up at the same time whenever a log is loaded!
  • Overlay: eventually got around to implementing *multiple* timers (to handle multiple overlay statements instead of clobbering a unique timer), phew :-)


3.1.4 "rushed biggie" (2007 07 03)
Fixes... Err... You want, err, fixes... Here's hoping I get closer to production-quality :-P Though on second thought, with my last minute fiddling with #Overlay, the prospects of being total-stable again might be deffered by one more build, whops..
  • The "Help" button is now officially retired! On a minor note, this means I've severed the 'link' to its help file (i.e. the help-on-help file that is simply named "help"... :-) that was accessible when right-clicking the help button itself, so that one file can be shelved I guess.
  • To replace the help-button, one may now invoke help via the keyboard, using the F1 key. Function keys used to cause problems (work here but not work at Dane's), but those were in Zeta days, it ought to work now that we're BeOS-max based I guess. (whops... what of our existing Zeta-using customer base then.. damn)
  • Changed a button label from "Audition ..." to "Preview".
  • Fixed the Shift-space/Space keyboard combos: the kbd code was a tad braindead, in that it would consider Caps-Lock and Num-Lock to be like a depressed Shift-Key, ugh :-) Works as it should, now.
  • Fixed a rare failed-assert in PreferencesWin.cpp: the media kit might, under Zeta apparently, sometimes return "zero" when queried about how many soundcards are installed in the system. This is dealt with thanks to an if() rather than an ASSERT() now.
  • Fixed the "real time awareness" of next-to-play, which was mistakenly enforced also at normal-log-loading-time, in addition to being enforced at reboot/cold-start: having this "extra" actually bought us nothing good, and on the downside, it did entail a funky-looking next-to-play (retarded by one line) until "auto-on" was depressed.
  • Fixed Prefs-Window's excessive width, which was caused by the recent changes in the "reboot recovery" box. Shortened its labels a bit, and transferred some of my verbosity into the "online help byline box" where it belongs instead :-)
  • Refactored class LatchRelayHandler (the one in charge of relay-triggered HotTracks) so as to make it easier to implement #Overlay.
  • While doing this, also ended up fixing a stupid bug where the case-insensitiveness on the BQuery'ed attribute ended up being stored into the rotation table itself, thus likely screwing up the rotation cycle.
  • *Not Production Grade Yet* (in fact, not event *tested* much) : got started on Overlay, looking forward to introduce it in the *Next Build*: new syntax, #Overlay, Going like, # Overlay :05:30 Comment SomethingOrOther This feature designed to *not* be listview-visible. This feature designed to be available only with the right *keyfile flag* ("TT professional", just like HotTrack and Route-For and stuff). Currently ONLY SUPPORTS *one* overlay configured at a time (clobbered each time you re-issue the syntax). Yep, that's a trial balloon for this feature :-) RUNNING INTO A FEW ISSUES ALREADY: * As the Overlay currently code stands, overlays will be executed as scheduled, even if the user has momentarily *stopped* *automation* just before said time (!) Gotta make sure my EventsServer is aware of the automation status or something. Or (better) move the whole thingamadokie from EventsServer.cpp to TransitionEngine.cpp ?? (come to think of it.... THIS BUG MIGHT ALSO EXIST for the older code I had written for relay-triggered HotTracks ? What if a relay closure happens while automation is off ??) So many questions, so little time to code it all :-P * Gotta reset the "overlay handler" class each hour, so as not to leak resources (timers). Alternative (probably better): periodically check for the status of all registered timers -- if any are "in the past", then obviously discard them. * In a "reboot recovery" scenario (as well as other scenarios), TuneTracker might skip over an #Overlay statement, ignoring it completely, even though (I suppose) the DJ's intent is to do apply them: just because you 'jump' into an hour block mid-stream, doesn't mean you want to ignore it's "overlaid tracks" that (although configured at the start of the hour) are scheduled to happen in the future of the hour... Right ? I have no idea how to technically solve this, if this ends up being an issue indeed... (Dane's call). * On the contrary, if one or more #overlay statements are stumbled upon, whose time digits are IN THE PAST (e.g. they say :30:00 even though the wall clock says the time is 5:35:00 PM) the current version of the code seems to "panic catch up", to flush everything at once (launching all "overdue" overlays!), which is not a behavior we want, right ?


3.1.3 "Audition and shift-space and stuff and oh my" (2007 07 25)
Lots of things put together a bit hastily, so you might want to write me a wish-list of things to "polish" if you encounter bugs :-]..
  • AUDITION: FIXED ! Tested to work with SB64 "Ensoniq PCI". Tested to work with "AC97 / ICH". Tested to NOT work with SBLive "emu10k" unfortunately.
  • To 'celebrate' the newly working audition feature :-P, also improved (restored) the layout of the system buttons. Almost back to what they used to be, except of course we're still missing the "Help" button, clobbered (thus far) by the "Audition" button, until we decide what GUI form the Audition feature should have.
  • Fixed the "adopted tracks have exagerated countdown time" bug. The progress-bar that is displayed is kinda perfect now (i.e. it starts "within range", just like it should be, mimic'ing the one from SoundPlay itself).
  • Also improved the looks of the progress bar for "shift-spacebar'ed tracks" the same way (no longer arbitrarily offset to zero, they start "within").
  • In the process of fixing those bugs, found ANOTHER one (ouch) in class PauseProxy: silly me, the "skipThatManySeconds" value was interpreted as microseconds, even though it was expressed in seconds... This bug might have impacted several features... anyway it's gone now.
  • Changed the "start at exact place" keyboard shortcut, from Command-G to SHIFT-Space.
  • Modified the "start at exact place" feature so that, when invoked from the keyboard, it will recalculate the event-cursor (rather than assume it to be correct).


3.1.2 (2007 07 17):
New features ? Ya want new features ?
  • Fixed the "suicide" (ASSERT() statement) in ActiveEventProxy::removeEventLineFromGuiModel()) upon NULL node value: 'node' might indeed be NULL when an event dtor is called after scratchAllReferencesToDefunctPlayer() has been called !
  • Fixed the "pesky drag n drop" bug: in BlockyElem.cpp, fixed a stupid (beginner-programmer-grade) lack-of-variable-initialization bug, which led to BlockyElem's starting a DnD session "out of the blue" when hovering the mouse pointer over them while e.g. using the Big Volume Slider.
  • Implemented TrimStart and TrimEnd ! Felt very natural to code now that the code makes it easy to add that kind of feature. Trimming is now completely transparent to the rest of the code, i.e. its "maths" are done first, all the rest (Segues ..etc) second. TuneTracker now deals with those two BFS attributes, of type "float": "tunetracker:trim_start" and "tunetracker:trim_end" I've tried this new feature on "BeOS talking blues" (which is 10 seconds too long for my taste) and another mp3 (which has too much silence at the beginning), and it works very very well indeed! Needs testing...
  • Reboot recovery: the "under the hood" part: In App.cpp / case kBRS_START_CURRENT_NEXT2PLAY, replaced the call to StartActiveEvent() by a call to StartActiveEventAtExactRightPlace() (depending on the user preferences). Needs a bit of testing..
  • Talking of user preferences, here's for Reboot recovery and ProgramLog loading in general:
  • PrefsWindow GUI: got rid of the checkbox with these strings: "Resume at the "exact best place"" "super_granular_cursor_auto_placement" "Start at the one line within the hour that is the most "precise" as per simulation, rather than a rough time-corrects-based approximation."
  • Instead, replaced it with a combo box that provides not two, but three options to the user.


3.1.1 "Two Tricks Pony" (2007 06 28):
And it's the start of another developement cycle! This pony learned 2 new tricks: real-time awareness (prototype code) and audition (even less polished code yet..)... I'm not proud of the code advancement at this stage, but the first trick of the two is poised to improve some day, I'm sure :-)
  • GUI / Prefs: Added a discrete little "audition" combo box in the last Preferences page.
  • Added an "Audition" button in the main window; this messes up the layout real bad (and "disappears" the Help button), but is only temporary for experimenting purposes, no worry :-) Though anyway, Audition always fails here with whatever soundcard I try, with a BSoundPlayer error ("no mixer") :-( This very much seems to be driver related, since I also failed to establish the connection to the driver when using the BeBits.com utility "Cortex", in all but one instance, which seemed to have been a "freak success" anyway. So I'm leaning towards this explanation: it seems that instantiating the sound-card drivers as "warm start" fails to initialize the hardware properly most of the time ?! We're fooked :-( Anyway try it out with some other soundcard [drivers], just in case one of them is more "warm-start friendly" as the SBLive one and the AC97 one I have here.
  • Made a moderate (to the user) but very important (to me, coding-wise) change in the behavior of TT when a program-log is loaded up: TT will now position the cursor, not on the NEXT song that ought to be played "later on", but on the one that ought to be playing right now. This was of course necessary before implementing the below feature. Unfortunately this piece of code doesn't work very well if the real-time cursor is positioned on a #pause-for/#interrupt combo. Will be a PITA to fix. But anyway here we are with a prototype, which works fine in other scenarios that I could test:
  • REAL-TIME AWARENESS: implemented for physical events, for switcher events, URL events. I've only tested it with physical events, but all should work equally. The "Seek()" (cursor-within-cursor positioning) operation is decided at the very time when you hit the Command-G keyboard combo, meaning that you have quite some time before the launch of TT and the hitting of "Auto On" and the like, before the current-song becomes invalid (outdated). Even when the user does an "outdated" real-time-start request, TT will not freak out but simply do a best-effort attempt (i.e. start at zero or start near the very end, depending on which way has the user been unreasonable).
  • Wired "Command-G" to the above "real-time start" feature.
  • Prefs window GUI : "retired" the "restore previous program log queue" preference. TuneTracker will now _always_ apply persistency of the queue. (internals: that prefs used to have the string values: "Restore program log queue", "persistent_proglog_queue", "Save the list of Program Logs whenever modified and restore it again at startup." )


3.0.26 (2007 04 09):
No problem with Dane needing a build to show off a bit for those customers who are 'taking our pulse', I just happen this very evening to have fixed a couple features/bugs so it's a good excuse to do it!
  • Changed the button graphics ..etc, using the new "gradient" ones from Dane.
  • ToneTracker: Modified the BQuery code in relay-triggered HotTracks so that we have case-insensitive querying, on the "what attribute value field".
  • Modified BlockyElem::MouseMoved() so that "Get song info" will be triggered upon extended-touch-display, and not the pop-up-menu as previously. This will also save me the trouble of having to debug the DnD-occurs-at-the-same-time bug which seems to occur at times.
  • Did some behind-the-scenes cleaning up of the sources. Stil more to do.
3.0.25 (2007 04 03):
Dumb me! Fixed the issue du jour, I think :-)
  • Fixed the 'suicide' in ToneTracker's relay-triggered Hot-Tracks: Dumb me! I had made it a 'suicide condition' when ToneTracker failed to pre-load a track, even though this ought to actually NOT warrant a suicide, since this may in fact happen very easily: the "rotation" parameters just have to be invalid (i.e. yield a query that yields nothing) for this problem to occur ! Lesson learned -- ToneT will no longer bring down the app any more for this now, but instead will print something in the ReportLog going like : 21:10:46 ** ToneTracker ERROR: in function Trigger() of latch-relay-handler: pre-loaded track occurs to be uninitialized/misinitialized ! Most likely error is that we couldn't rotate with those settings: queryAttrName=Audio:Genre and queryWantedValue=Bl___ues. [ Looks like I'm not done with HotTracks yet, though, Dane also mentionned this: --HotTrack events are also not entirely "invisible to the GUI."-- ]
  • Disabled printf() debug dumps in ToneTracker, will be a while before we need them again I guess.
  • GUI / Clock and weather: Restored the 10-pixels padding to the right of the clock, so that this row of the GUI looks symmetrical (same padding on the BWeather area at the left and on the clock to the right).
  • GUI / Event-lines look and feel: introduced some new "drag threshold" code, so that it's easier to open the pop-up-menu with a touch-screen: the "drag" part of the drag-n-drop session will now only be triggered by above-4-pixels pointer moves, otherwise it's the pop-up-menu that gets triggered.


3.0.24 (2007 03 31):
Ramp countdowns, universal overlap and touchscreen-friendly pop-up-menu are on the menu !
  • GUI / Event-lines / Pop-up-menu: modified the "Get song info" label so that it's appended with an ellipsis (triple-dot). At first this sounds like a bad idea (not compliant with the Be GUI Kit style-guide) but in fact it's consistent with what we do elsewhere, i.e. the "Help..." menu item is similar.
  • GUI / Event-lines display: modified the "Ramp:" label code, so that the displayed time actual "counts down" when the event starts playing.
  • Segues: modified the BFS-attribute retrieving code so that a file that does not have a Segue-In, gets treated exactly as if it had a Segue-In of [whatever value is configured for "Normal Transition" in the Preferences], and same thing for Segue-Out. Which means that Universal Overlap is back !
  • Enlarged the BWeather area, as much as I could without sacrifying the Time display. Did this by shortening the Time display harmlessly, which was done by ... 1/ removing padding on the right 2/ removing padding on the left. Let's see how it goes; it this is still not enough, we'll have to get rid of the "seconds" part of the Time display or something like that, which will give us 3 more characters... Or maybe reduce the font-size of the weather display itself..
  • Modified BlockyElem::MouseMoved() et alia to be NetPositive-style, i.e. so that one may trigger the pop-up-menu of a blocky Event-Line by holding the left mouse button for two seconds. Which means that it ought to work also with TouchScreens, "Get event info" feature included ! Also modified the older "drag n drop Event Line" code so that it is only triggered when the mouse starts moving now -- which ensures the older DnD code won't interfere with the new Netpositive-style code.
  • While not directly addressing head-on the "relay bug" entry in the Do-List, I've tried re-enabling the "restartPlayer()" call in EventsModel.cpp. From where I stand, this seems to get rid of the soundplay "can't connect" error alert, and to also get rid of the "no file" track within soundplay; Dane will probably want to experiment and tell me if this is throwing the baby with the bathwater, or if it is a workable solution...


3.0.23 (2007 03 17)
  • Added a global TTCC hot-key for a new look-and-feel feature: the "Enter" key now acts as a toggle to shrink/expand the lower-right Text View. (also works with the "Return" key, as a BeOS free 'feature'...).   Tested, works fine!
  • Added SEGUE code, based on attribute names "tunetracker:segue-in" and "tunetracker:segue_out". It's a fairly simple implementation right now, no bells and whistles: when the attribute is not present on a given file, TTCC does not attempt to "guesstimate" the segue value based on another attribute or anything like that -- which means that attributes-less files will have zero overlap at all...   TEST RESULTS: Works nicely for transitions. Need to re-institute universal overlap. Panic doesn't completely do its job on breaking away from a cut that has segue transition marked. Song keeps playing. Also I am seeing some instances where a "non-song event" seems to sit and do nothing for awhile and then advance. I'll try to figure out what is causing that part, but it first appeared in this build, I think.
  • GUI / Event-lines / pop-up-menu: added a "Get song info." item, that retrieves the "Audio:Info" field of the concerned event and loads it up into the lower-right Text View.   Tested, also exactly right! Let's add two more dots to the end of the option in the right-click menu, as in "..."
3.0.22 (2007-03-10)
Fixes again...
  • PreferencesWindow/Misc pane: Fixed the path for launching Pe, as set into the combo box from within PreferencesWindow.cpp, from "RealPlayerTuneTracker System" to "TuneTracker System".
  • PreferencesWindow/Switcher pane: Changed a label string from "Permanent connection (default TuneTracker channel)" to "Reserve switcher channel for Command Center audio"
  • Fixed a stupid bug w.r.t. performing Relay-triggered-hot-tracks: LatchRelayHandler::Trigger() was dumbly deleting the "current playing" at the time of the pre-loading of the "pre-loaded", hence nothing ever played (nothing was ever "current" for any significant time of more than a few milliseconds).
  • Fixed the "SP at front" annoyance: ever since the HotTracks "preload optimization" started, SoundPlay is "instantiated" twice (as a 'proxy' within TuneTracker, at least), meaning it is brought to front even after the main GUI has been created; I have now supplemented the proxy code so that it does a "pull TuneTracker to front" call, so that TT eventually wins the tug of war for user attention :-)


3.0.21 (2007-03-08)
Adding new and fixing old stuff...
  • Re-enabled the "debug print-outs" of ToneTrackerLooper.cpp so as to diagnose Dane's /dev/ports/usb0 troubles...: It would seem that with the zeta 'exotic' usb-to-serial driver, * the BT-box silence-sensor is broken, * using a hot-button like "route input 1 to output 1" no longer works.. In fact, only incoming relays are still performing correctly.. ?!
  • GUI / Prefs Window / "Switcher" pane: Added a combo-box that allows to pick up which serial port to use, so that Dane may switch back to the old "pure serial" connection and check that the BT box STILL WORKS AS it is supposed to when using a non-exotic 'real' serial connection to it :-) We will then know if TT has regressed, or if it's the usb0 thingy itself which is the culprit...
  • Added the necessary logic within EventsServer.cpp and EventsModel.cpp so as to make ToneTrackerLooper.cpp use this new preference (shutdown and re-start ToneT whenever the value changes ..etc).
  • GUI / Prefs Window / "Misc" pane: Added a (hardcoded, first-in-line) entry in the "select editor" combo box, like "/boot/apps/TuneTracker Systems/Extras/Pe/Pe" . TuneTracker will know to "launch by path" instead of "launch by signature" when the user selects this entry.
  • Quick (and supposedly CLEAN!) fix for Relay-hotTrack, yet with no "GUI fix" yet: The issue is -- currently, once I queue up a track for future replay, I "detach" the C++ object from the track.. Because I "know" it will be handled (cleaned up) as necessary, by the GUI... But this "know"ledge is bogus currently !! They only WANT one thing to fire when there's a relay. Multiples would be an evil menace from Mars So if I no longer detach, then it makes things easier -- I keep full control of the "life cycle" of the track, never forget to clean it up when needed.. But there can be only one track per relay closure, on the other hand. --> though it also means that if an #ignore statement comes up, the currently-playing track will be ejected..


3.0.20 (2007-?)
A quick build to try out usb0...
  • Commented-out the debug output from ToneTrackerLooper.cpp again.
  • Hardcoding "usb0" instead of "serial1"
3.0.19 (2007-02-27)
Tweaking, refining, fixing, you name it! Also cleaned-up EventModel.cpp a bit.
  • Minor fix: slightly improved the wording of the reportlog error message about "cannot write so and so next-to-play textfile".
  • Commented out the restartPlayer() call within PlayerState::SetSecondaryAsAutomatedEventWithProps(). That way, SoundPlay will no longer be killed/restarted when a track affectation fails.
  • Modified the display of Switcher event-lines so that they no longer show the (ever-blank) "Running Time" and "Ramp" labels.
  • Improved the robustness of the "Update Web Site" feature that is to be found in the PreferencesWindow's "log" tab: if the ascynhronous-exec ampersand is not there, it is now automatically appended to the string that is passed to ::system(). This will prevent the main thread from being unresponsive to the other threads within the app.
  • Tweaking of Ramps timing: modified AudioFile::OnRamp() and AudioFile::OffRamp() so that, instead of returning the read attribute straight from disk, they return "attribute plus 500 ms" instead.
  • While doing a code review of ToneTrackerLooper.cpp, fixed two bugs, one in Unset() (most likely unrelated to Dane's pains with hot-tracks) and one in SetAsHotTrackCreator(), which could very possibly be the cause of the bug.
  • Just in case, enabled Debug Output within ToneTrackerLooper.cpp, will need Dane to do a "capture" of the Terminal output (as short as possible as always in this case :-) produced during the execution (or rather, lack thereof) of HotTracks...
  • GUI / PrefsWindow / Broadcast ops: created a new "Text Editor App" combo box to configure which app to choose for the "Open Program Log with..." file-editing feature. It allows to pick any app installed on the system that knows to handle the "text" MIME supertype. The fact that TTCC no longer hardcodes a particular app sig (e.g. BeOS StyledEdit) will be especially useful to Zeta users, whose sigs seem to be changing of late... Also to add some "polish" to this feature, made sure that any error that occurs when invoking the BeOS roster will be displayed in red in the modular "text box".
  • Also while working on the prev. feature, realized that the old "show an error message when encoutering a syntax error while parsing the log" thingy, could be improved: instead of launching StyledEdit, it will now display a red error message within the modular-text-box.


3.0.18 (2007-02-11)
Some fixes, improvements, optimizations, oh my ! I've got yer build right here :-)
  • Commented out the printf()s in BBitmapButton -- though didn't outright delete them, in case we need them later.
  • Re-enabled the ShuttlePad button code, which I had purposedly disabled/broken for TouchScreen testing purposes. Beside the message-filter workhorse, also re-enabled the SetTarget() call.
  • Fixed the "app suicide" happening when TransitionEngine::StartActiveEvent() is called on some oddly-configured program-logs: had already removed the other case, happening when the log is non-existent or outright empty, and now went at it liberally the whole way (!) and made sure this function will never ever get pissed off now, no matter what is thrown at it -- indeed, most oddball-states are not due to an internal bug, but simply due to user errors, and thus should not be "punished".
  • Regression that happened a few weeks ago: Whatever automated track(s) were active within SoundPlay used to be killed when TTCC would be shutdown cleanly: fixed that. Turned out to be a one-line fix (love when that happens! increasingly does, for that matter).
  • Pre-loading: Optimized the performance of Relay-HotTracks... at the expense of their "GUI side": lemme 'splain, TTCC's "ToneTracker" thread is now leveraging class "LocalFileEventProxy" to pre-load HotTrack, since the EventManager class does not allow for this -- but this means the GUI is no longer updated (the event does not appear in the listview when it starts playing). 2f1 Maybe this does not matter, because users don't care that those particular kinds of HotTracks are not visible in the list ? Will wait for feedback before doing head-scratching as to how to fix this...

Meta

This section discusses this very document.

Update Policy / Exclusive Hours: Cedric commits to only ever uploading this document between 7 PM and 2 AM C.E.T., meaning XXXXXX Wisconsin Time :-), meaning that Dane can freely upload changes outside this time window and be clobber-risk-free -- likewise, Cedric may assume it is safe to download the latest version at 7 PM, work on it off-line, and upload the modified version before 2 AM, since he knows for sure that no (potentially clobbered) changes will have been performed in the meantime.

Colors scheme: we'll use the following guidelines when it comes to colors: Cedric uses dark blue text (using the <font color="blue"> HTML tag) when he wants to highlite something special to Dane. Dane uses dark red text when he wants to hilite something for Cedric to notice.

General: indeed all dates must be in the yyyy-mm-dd format (e.g. 2007-02-28) :-P, otherwise we risk confusion (esp. on Cedric's side) -- either that or, at least, the e.g. 2007-Feb-28 format (letters instead of digits).

Since the Todo list is our master list of priorities, let's include "fix-mes" in the list too...because sometimes a fix needs to happen even before a new feature gets added.

oad changes outside this time window and be clobber-risk-free -- likewise, Cedric may assume it is safe to download the latest version at 7 PM, work on it off-line, and upload the modified version before 2 AM, since he knows for sure that no (potentially clobbered) changes will have been performed in the meantime.

Colors scheme: we'll use the following guidelines when it comes to colors: Cedric uses dark blue text (using the <font color="blue"> HTML tag) when he wants to highlite something special to Dane. Dane uses dark red text when he wants to hilite something for Cedric to notice.

General: indeed all dates must be in the yyyy-mm-dd format (e.g. 2007-02-28) :-P, otherwise we risk confusion (esp. on Cedric's side) -- either that or, at least, the e.g. 2007-Feb-28 format (letters instead of digits).

Since the Todo list is our master list of priorities, let's include "fix-mes" in the list too...because sometimes a fix needs to happen even before a new feature gets added.

Return to Top

Make your own free website on Tripod.com