A way to add tracks?

[South8028]

https://disk.yandex.ru/d/OGbJxadXlXGhZw

I made a tape recorder (photo of an old Crown tape recorder, made in the USA in the 1960s) and vintage speakers (need to be altered a little). Is there an advanced way to add music? Previously, on old speakers I used very long animations and tags for soundNode, for descriptors in ck. But this method is idiotic because it requires super-long animation, has no track selection, uses fake descriptors between tracks (tags are glitchy, and gamebryo can confuse short and long audio and there will be half an hour of silence instead of music). I'm looking for a more advanced way. Does anyone have any ideas?

 

[ChuckYufarley]

There's several ways you can go about setting up the tracks to play. It all depends on how simple or complex you want the recorder to function. Do you have any experience with writing scripts? 

When I made my first jukebox mod, I wrote a script that would play the tracks directly via sound descriptors. When I made my second jukebox, I wanted to add volume control, so I set up a quest with scenes for each track, and that allowed me to set up the speakers to act like a radio, with volume control, and the ability to place them anywhere.

Since your tape recorder doesn't have all the buttons as a jukebox for making selections, scripting it for track selection would involve a pop-up menu. If you don't want a pop-up menu, you could script it to play randomly from a list of tracks.

Right now you have the recorder using the generic workshop behavior, I assume so that it powers on when connected to a power source. If this were my project, I'd eliminate the behavior, set up animation sequences for off, lights and meters powering on, reel-to-reel playback, lights and meters on, and lights and meters powering off. 

In a script I would use PlayGamebryoAnimation  to play the lights and meters powering on sequence when power is attached. Lights and meters powering down sequence when power is disconnected. On activation play the reel-to-reel animation as well as track audio. When song is complete, play the lights and meters on sequence. With this setup, as long as it's attached to power, lights and meters will always be on, and playback can be activated over and over without the recorder appearing to shut down.

Again, it all depends on how simple or complex you want it to behave. You could use GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx as a behavior, with 4 animation sequences. Stage1, stage2, stage3 and stage4. Stage1 is off, stage2 is lights and meters powering on. Stage3 is reel-to-reel animation (looping). Stage4 is lights and meters powering off. With this setup, it would repeat the powering on, playback, and powering off sequences every time you activate it to play a track. You could add the OnPowerOn/OnPowerOff events to the script to control activation of the object, so that you can only activate it as long as it's connected to power. 

If you're wanting to avoid using sound descriptors altogether, I'm pretty sure F4SE allows for MP3 playback. However, I've never done this, and considering the state of F4SE at the moment, this might not be an option.

If scripting is out of the question, the simplest way I can think of is to use the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior with 4 animations sequences as before. In the NiTextKeyExtraData of Stage2, set a key that points to stage3 when the stage completes, and a SoundPlay key in the NiTextKeyExtraData of Stage3 that points to a sound descriptor that includes all your tracks. This should result in one of the tracks randomly playing each time it's activated. In the CK set up the recorder to use the Default2StateActivator script and set up the properties so that Stage2 plays when the recorder is activated. Again, this will result in the recorder powering on, playing and powering off each time it's activated. Also, there's no way to implement connected power with this method. It's been a while since I used the Default2StateActivator script, and if I'm not mistaken, you'd have to activate it a second time when the track completes in order to shut the recorder off. 

I hope this helps. I tried my best to limit my usual wall of text.

[South8028]

5 minutes ago, ChuckYufarley said:

There's several ways you can go about setting up the tracks to play. It all depends on how simple or complex you want the recorder to function. Do you have any experience with writing scripts? 

When I made my first jukebox mod, I wrote a script that would play the tracks directly via sound descriptors. When I made my second jukebox, I wanted to add volume control, so I set up a quest with scenes for each track, and that allowed me to set up the speakers to act like a radio, with volume control, and the ability to place them anywhere.

Since your tape recorder doesn't have all the buttons as a jukebox for making selections, scripting it for track selection would involve a pop-up menu. If you don't want a pop-up menu, you could script it to play randomly from a list of tracks.

Right now you have the recorder using the generic workshop behavior, I assume so that it powers on when connected to a power source. If this were my project, I'd eliminate the behavior, set up animation sequences for off, lights and meters powering on, reel-to-reel playback, lights and meters on, and lights and meters powering off. 

In a script I would use PlayGamebryoAnimation  to play the lights and meters powering on sequence when power is attached. Lights and meters powering down sequence when power is disconnected. On activation play the reel-to-reel animation as well as track audio. When song is complete, play the lights and meters on sequence. With this setup, as long as it's attached to power, lights and meters will always be on, and playback can be activated over and over without the recorder appearing to shut down.

Again, it all depends on how simple or complex you want it to behave. You could use GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx as a behavior, with 4 animation sequences. Stage1, stage2, stage3 and stage4. Stage1 is off, stage2 is lights and meters powering on. Stage3 is reel-to-reel animation. Stage4 is lights and meters powering off. With this setup, it would repeat the powering on, playback, and powering off sequences every time you activate it to play a track. You could add the OnPowerOn/OnPowerOff events to the script to control activation of the object, so that you can only activate it as long as it's connected to power. 

If you're wanting to avoid using sound descriptors altogether, I'm pretty sure F4SE allows for MP3 playback. However, I've never done this, and considering the state of F4SE at the moment, this might not be an option.

If scripting is out of the question, the simplest way I can think of is to use the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior with 3 animations sequences. Stage1 off. Stage2 power on and reel-to-reel playback. Stage3 power down. Then, in the NiTextKeyExtraData of Stage2, set a SoundPlay key that points to a sound descriptor that includes all your tracks. This should result in one of the tracks randomly playing each time it's activated. In the CK set up the recorder to use the Default2StateActivator script and set up the properties so that Stage2 plays when the recorder is activated. Again, this will result in the recorder powering on, playing and powering off each time it's activated. Also, there's no way to implement connected power with this method.

I hope this helps. I tried my best to limit my usual wall of text.

Thanks so much, as always, Chuck. The second method looks doable. To implement the first method, I will need not just long text, but step-by-step instructions. I’ll make do with the second method. When I get to setting up Default2StateActivator, I will probably turn to you again for help. Because I don’t know what values should be set there. In terms of the complexity of switching, specifically in 3D, I don’t care how many switches to make, or how many sequences to use. I don't like to mess with scripts, but I can make any kind of animation.

[ChuckYufarley]

If you want to be able to select tracks, it's going to take some scripting. Now, since you said you can add as many switches or buttons as it takes to select all your tracks, I'd be more than happy to help you out with the scripting. And by that, I mean writing the script for you. It would take a lot less time for me to just write the script than try to explain it to you. AND by that, I don't mean you wouldn't understand my explanation, but my explanation would probably go on far too long...as usual.

Here's what you need to do. When you create the switches/buttons, they need to be exported as individual nifs. You really only need to make one, and we can just use it over and over for each instance it appears in game. You can animate the switch/button if you want, it doesn't matter. In the recorder nif, you need to make a NiNode for every position where you want to place a switch/button. Name them Button_01, Button_02, etc. It doesn't matter what you name them, they just need to have unique names and be in the right spot.

In the script, when the recorder is placed in game, it will spawn each button in it's proper place as an individual activator, so that each one plays it's own track when selected. Make sure the buttons have their own collision that sticks out farther than the collision for the recorder itself, otherwise they won't be selectable.

[South8028]

13 minutes ago, ChuckYufarley said:

If you want to be able to select tracks, it's going to take some scripting. Now, since you said you can add as many switches or buttons as it takes to select all your tracks, I'd be more than happy to help you out with the scripting. And by that, I mean writing the script for you. It would take a lot less time for me to just write the script than try to explain it to you. AND by that, I don't mean you wouldn't understand my explanation, but my explanation would probably go on far too long...as usual.

Here's what you need to do. When you create the switches/buttons, they need to be exported as individual nifs. You really only need to make one, and we can just use it over and over for each instance it appears in game. You can animate the switch/button if you want, it doesn't matter. In the recorder nif, you need to make a NiNode for every position where you want to place a switch/button. Name them Button_01, Button_02, etc. It doesn't matter what you name them, they just need to have unique names and be in the right spot.

In the script, when the recorder is placed in game, it will spawn each button in it's proper place as an individual activator, so that each one plays it's own track when selected. Make sure the buttons have their own collision that sticks out farther than the collision for the recorder itself, otherwise they won't be selectable.

Oh this is great. Then... What sequences should I use? Are sequences needed for the tape recorder base itself? Do switches need sequences? Will the sound be played from the tape recorder or speakers? I can, for example, make wires with a bs connect point so that they curl along the floor and connect to the speakers from the tape recorder... Are switches needed on the speakers? Also, it should probably be added that I did not update the version of fo4. I have 1.10.162.0. If it's important...

Edited May 17 by South8028

[niston]

In case the speakers are setup as actual sound emitters, you could control (track and volume) a number of them from the recorder via NetLink. Personally, I'd implement the system to be fully geared towards wireless power, but ofc it would work across workshop wires as well. Speakers could be placed wherever the network reaches, you could setup many of them in groups that can be individually switched (remember those SPEAKERS A/B switches on older amps?). Other people could make other speakers that implement the same protocol and they could work with your recorder. Similar, your speakers could also work with other people's players/recorders.

It would be easily possible to also implement a remote control that can be placed on a desk or table or wherever (and works by wireless) for your recorder, based on the same networking technology.

If anyone feels like doing it, I'd be happy to register a protocol number for it and maybe help develop the actual protocol. I'd suggest it'd be called SOUTHLINK-AUDIO (SLA), with protocol number 8028 of course.

[ChuckYufarley]

The animations for the recorder depend on what you want it to do. If you want to be able to utilize connected power, and you don't want the lights to switch off between songs, make the sequences like I described in the example using no behaviors. Off, lights turning on, reel-to-reel animation (with lights on), lights on but no reel-to-reel animation, and lights powering off. Animated switches should have 2 sequences, Stage1 and Stage2. Stage1 no animation. Stage2 animated. For the reel-to-reel animation, you might want to delay the animation for a split second to allow for the timing of the button animation. 

If you want to place the speakers separately from the recorder, we can do the same thing I did with the second jukebox, make them act like radios. The sound will play from them and you'll be able to change the volume if you want. The volume adjust would require a pop-up menu, and if you want, an animated volume knob. I don't know if playing the speaker animation is possible doing it this way, though. At least not in sync with the music.

Otherwise, if you want the sound to come from the speakers, you could make them as part of the recorder nif and place NiNodes where you want the sound to come from.  My scripting knowledge is limited however, when it comes to placing objects separately, but having one script control everything. I'm sure it's possible,  but I've never done it. I could write the script so that it spawns the speakers, and then you can move them to where you want them,  that way I can still have the sound play from them and you can use the speaker animation as well. No volume control, though.

I did install the update, however. I'm not sure how that would impact this project.

 

Edit: I just looked at that NetLink mod and it looks really cool. I'm going to have to investigate that one for sure. Is F4SE working at this point, or are we dealing with a rolled back game? 

[niston]

@ChuckYufarley For NetLink to work with updated game, just fully updated F4SE alone won't cut it - SUP F4SE will have to be completely updated as well. I might be a while before that happens, esp considering Beth might push more updates who knows.
It is very unfortunate luck that a lot of the game's internal power grid functions (some of which are essential to NetLink operation) have changed with the 980 update.

[ChuckYufarley]

South, we could make the speakers as radios, AND spawn them with the recorder, that way you can move them around, have sound coming from them, have the volume control, and play the speaker animation. I've never done it, but I'm pretty sure you could still implement the connecting wires, at least for aesthetic purposes. Not sure how to handle the wires transmitting power needed for the speakers, but I'd say it's doable.

[South8028]

8 hours ago, niston said:

In case the speakers are setup as actual sound emitters, you could control (track and volume) a number of them from the recorder via NetLink. Personally, I'd implement the system to be fully geared towards wireless power, but ofc it would work across workshop wires as well. Speakers could be placed wherever the network reaches, you could setup many of them in groups that can be individually switched (remember those SPEAKERS A/B switches on older amps?). Other people could make other speakers that implement the same protocol and they could work with your recorder. Similar, your speakers could also work with other people's players/recorders.

It would be easily possible to also implement a remote control that can be placed on a desk or table or wherever (and works by wireless) for your recorder, based on the same networking technology.

If anyone feels like doing it, I'd be happy to register a protocol number for it and maybe help develop the actual protocol. I'd suggest it'd be called SOUTHLINK-AUDIO (SLA), with protocol number 8028 of course.

I would be happy if it was called NistonLink, or ChuckLink, as long as it works. Then I'll make a base for Chuck. Various switches, effects, speakers, wires, I can also make a remote control (although I don’t really understand what a remote control made in 1960 should look like. I had an old Soviet semi-digital radio made in 1957 with a remote control, but the remote control was wired   https://www.google.com/search?client=ms-android-samsung-ss&sca_esv=a29612ca3499ae85&sxsrf=ADLYWILkV0sy45TVbEUU2nMulbaNqlLBkg:1715938368654&q=радиоприемник+фестиваль&uds=ADvngMhqpErmKGhStdy5ktRc6NxJ_pHPdLsm2T3xnU2IU1OPlEo0SXk3rfrvbo2_V781XI8s833COtKAvBh3eWDRQkb32KCpDZwZ7pZvAnYAFzqzhBKfH92WFwcwkix4USjNNLP8IJuJCIe7MeP3PL8qY7sjAig_fKBwzhnNHgUkKC-b5bONkYNTOO56N_01TX8gia6aSNyJ6E5rg_mSOzmAItlXKTWwLcnNOrwbT3VGPjjGfJvotH9jhcJYZvPTwCLSZYuri1ndW5iLq3YIdTkeIRMkeA4wv4eVQeS80VjxbqaNBImKYR1ZAU68QkqppkcaSdeNRPBAdqH8RZd0Y7Rt9Uzzq3qh3Skc-QwmfA98dfUaf-NwpmQQ-fLfyLUFtsY3d8wF55m8qaeQGtnJSFj3RG_5uKee9Q&udm=2&prmd=ivsnmbt&sa=X&ved=2ahUKEwjM5q3HsJSGAxUoJRAIHW_cCcgQtKgLegQICxAB&biw=384&bih=719&dpr=2.81#ip=1 ) And you can also experiment with them as you like and do whatever you want. When I do, I'll post the link here.

Edited May 17 by South8028