![]() ![]() ![]() the structure would be primary_id, foreign_id, version, content. the verse content can potentially have hundreds of versions so it would be better stored in its own table and linked with a foreign key to identifying the references. The references are static (book, chapter, verse) so they can be populated in one table with an id and with that you have the framework of the entire bible. Vn just seems to be looking at the problem like a spreadsheet rather than taking advantage of what a DB has to offer. so id, book, chapter, verse, V1, V2, V3, V4. In the interface you can strip them off based on user's choice whether he requires red letter or small caps.įor reference, you can download the SQLs from below and customize in your wayĮxpanding the DB horizontally isn't very efficient with the potential of having very large tables and complex updates. Well, Small caps & Red letters you can store in version columns using HTML or appropriate formats. Oh, What about the Small caps and Red letters? `AMP` text NOT NULL, - Keep, keep, keep adding columns and good luck with future expansion `commentary` text NOT NULL, - Commentary, Keep adding more columns based on commentaries by difference authors `cross_reference` int(11) NOT NULL, - Integer/Array of integers, Just store `id`s of related verses `foot_note` varchar(1000) NOT NULL, - Store foot notes here `section_title` varchar(250) NOT NULL, - Section title, A section starts from this verse and spans across following verses until it finds a non-empty next section_title `book` varchar(25) NOT NULL, -Book, chapter, verse is the combined primary key `id` int(11) NOT NULL AUTO_INCREMENT, -Global unique number or verse That said here is my recommended table structure. Also, I will request you to realize the convenience of keeping the combination of ('Book, Chapter, Verse') as the PRIMARY key because in most situations that's the look-up way. When you add more version in future your table grows horizontally which is okay thus the # of rows remain constant(31102). Luckily the different version names are just kept as column wide. Information that isn't dependent on individual versionįor various reasons I prefer to store the whole bible project into one SINGLE table, Yes call it as bibleįor your visual here is my screen I have stored nearly 15 versions of bible in single table. Information that's dependent on individual version Considering your requirement we can split them into two major parts Click on the list item in the dock to change slide.SQL is the BEST way to store this.All the slides are cached into OBS, so there is no need to keep OpenSong running (Save CPU and RAM).If you still have the same issue, then start presenting on OBS. If the dock is stuck on “Loading…”, please right-click on the dock, and select reload.To navigate to a specific slide, click on the corresponding row from the dock to display in the browser source.At this point, you can stop presenting on OpenSong if you wish because every slide is cached.The full list of songs/verses should be displayed on the dock and the browser source should be displaying the rendered slide. Launch OBS, and start presenting on OpenSong.You need to have OpenSong installed with some songs and Automation API enabled in General Settings > System on port 8082.Next, in your scene(s), add a Browser source and select client.html from the extracted folder. ![]() Open OBS Studio, add a custom browser dock and select dock.html from the extracted folder.Download the plugin and unzip it where you want.Notice: This is still a WIP and I would appreciate if you could leave some comments requesting some features/bug fixes. It is inspired from OpenSong Controller by goorkamateusz which unfortunately did not meet my requirements, so I decided to create my own plugin to better suit my needs. This is a custom plugin that I made for OBS Studio to integrate OpenSong directly into OBS Studio. ![]()
0 Comments
Leave a Reply. |